<< Retour à l'affichage précédent

[EXP-3207] BI : accès à BI lorsque le site est en maintenance Création: 31/janv./07 10:08  Mise à jour: 25/juin/07 19:00  Résolue: 13/mars/07 17:31

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Agathe Remy Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Bonjour,

Lorsque le site est en maintenance, l'application BI est aussi passée en maintenance.
Ce n'est pas normal : pouvez-vous y remédier?

Merci:-)

Agathe

 Commentaires   
Commentaire de Antoine Koener [ 31/janv./07 15:45 ]

Le site est reUP
Commentaire de Antoine Koener [ 31/janv./07 16:07 ]

Il faut séparer les services pour les internautes des services pour l'interne.

Je vais donc sortir
bi.priceminister.com
du reste des serveurs et le rendre actif à tout moment, tant en mode production qu'en mode maintenance.

Peut être que d'autres services pourront être déplacés de la même façon ?

Commentaire de Antoine Koener [ 07/mars/07 14:36 ]
Il faudrait maquetter la chose suivante:

-extraire la configuration du vhost bi.priceminister.com de la configuration globale de apache, pour en faire un vhost normal
- desyncrhoniser le mode maintenance de ce vhost avec les autres.

Afin de réaliser la desynchronisation il faut simplement que dans le repertoire maintenance ce trouvent des fichiers de configuration identiques à ceux de production pour le vhost bi.

La bascule entre prod et maintenance ne doit pas avoir d'effet sur le vhost bi.
Il faut donc que le jk, les rewrite et autres soient les memes entre prod et maintenance pour bi.

A dispo pour en discuter.
Commentaire de Jérémie Bennejean [ 12/mars/07 12:32 ]
Ok, je fais le test en pre prod, ensuite sur la prod.
Commentaire de Justin Ziegler [ 13/mars/07 09:48 ]
pour info, QV est deja comme cela.
meme si le site est en maintenance, on a toujours acces a QV
Commentaire de Jérémie Bennejean [ 13/mars/07 17:29 ]
vu avec Antoine,

Le vh bi ne pointe jamais sur le repertoire maintenance mais tjrs sur production.
Quelque soit le mode, les rewrites rules et jk interrogés sont tjrs ceux de production.

Conclusion: le script pmapachemaintenance n'impactera jamais bi.priceminister.com
Commentaire de Justin Ziegler [ 13/mars/07 17:54 ]
heu ?
c pas clair la !
tu es en train de dire qu'il n'y a pas de pb ?
ou tu es en train de dire que tu as resolu le pb en faisant une modif ?
Commentaire de Jérémie Bennejean [ 13/mars/07 18:15 ]
Une modification a été faite afin de résoudre le pb.
La voici:

Include conf/production/rewrite.rules
Include conf/production/mod_jk.redirect.bi

Quelque soit le mode, le virtualhost bi est toujours accessible.
Nous avons testé avec un autre vh en pre prod.





[EXP-2514] BI : procédure de redémarrage des serveurs BI en PROD Création: 07/août/06 15:42  Mise à jour: 16/avr./08 13:47

Etat: Ouvert
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Sébastien Raguet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Bonjour,

Serait-il possible d'inclure le redémarrage des applis BI dans les procédures de redémarrage en Production :
- les instances OWREP, BOREP et DW sur latone
- les services BusinessObjects sur tellus

cf doc de JEB pour la DEV.

Merci:-)

Agathe

 Commentaires   
Commentaire de Antoine Koener [ 09/mai/07 17:53 ]
Voici une bonne suggestion :p
Peut être travailles-tu déjà sur cela ?
Commentaire de Agathe Remy [ 15/avr./08 14:52 ]
Bonjour Patrice,

Sais-tu si cela a finalement été fait? Ou bien attend-on la migration sur le serveur dédié?

Merci:-)
Agathe

Commentaire de Patrice Boulanger [ 15/avr./08 15:02 ]
En fait, étant donné qu'on a des alertes sur les process BO sur Tellus et à terme sur le serveur BI dédié, ça devient moins urgent. En cas de plantage de la machine, même si on oublie de relancer les services BO, on recevra des alarmes.

Ceci dit, il est toujours prévu de mettre en place des procédures dédiées par serveur donc ce sera le cas pour le serveur BI.
Commentaire de Patrice Boulanger [ 16/avr./08 13:47 ]
Sébastien, à inclure dans les procédures en cas de crash de serveurs.

Merci.




Migration du mécanisme d'import des fichiers de Phaeton vers Bacchus (EXP-2759)

[EXP-2764] Migration des services B.I. Création: 29/sept./06 14:17  Mise à jour: 25/juin/07 18:59  Résolue: 02/janv./07 10:46

Etat: Résolu
Projet: Exploitation
Composants: Evolution
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Critique
Rapporteur: Patrice Boulanger Attribution: Eric Vannier
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Le B.I. utilise Phaeton à plusieurs niveaux:

1. transfert de fichiers vers la plateforme de prod en scp:
      -> aujourd'hui, les fichiers sont copiés dans /tmp/agathe sur phaeton
      -> prévoir un répertoire spécifique pour le B.I.

2. latone, titan et junon copient et cryptent des fichiers sur phaeton pour les envoyer en FTP (et peut-être HTTP cf. François) vers les partenaires.
      -> vérifier l'installation de gpg sur bacchus
      -> copier les clés de cryptage de phaeton sur bacchus
      -> migrer les scripts du B.I. vers bacchus
      -> migrer la copie depuis latone, titan et junon vers bacchus et valider le transfert vers les partenaires.

 Commentaires   
Commentaire de Eric Vannier [ 02/oct./06 14:53 ]
1°) J'ai crée un répertoire "bi" dans /tmp de Phaeton pour que celui-ci soit utilisé pour le transfert vers la prod.
Le B.I. est en charge de faire sa purge régulière.

2°) gpg est installé sur Bacchus, j'ai réalisé la copie des clés de cryptage de Phaeton sur Bacchus


Commentaire de Patrice Boulanger [ 02/oct./06 15:02 ]
J'ai mis Agathe en observatrice du JIRA pour avoir son avis sur la question et sa validation
Commentaire de Eric Vannier [ 17/nov./06 11:21 ]
La migration s'est bien passée du côté du BI.
Commentaire de Patrice Boulanger [ 02/janv./07 10:46 ]
Donc je résous




[BIN-520] [Tracking] : étude comparative DI / BI Création: 17/nov./08 17:01  Mise à jour: 17/déc./08 15:39  Résolue: 18/nov./08 18:24

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Mathieu Richomme Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Export_DI20081107-bis.xls     Microsoft Excel Export_DI20081107_01.xls     Microsoft Excel Export_DI20081107_02.xls     Microsoft Excel extraction panier tracking pour MKT le 18 11 2008.xlsx    
Liens des demandes:
Duplicate
doublon de BIN-505 [Tracking] : Extraction des last trac... Fermé
Pays:
FRA - France

 Description   
Bonjour Agathe,

en PJ un export avec les données DI
1 purchase id par ligne, pour chaque ligne nous souhaiterions compléter avec les données BI:
- last tracking 30 jours BI
- volume d'affaire BI
- commission BI

d'avance merci!
Mathieu

 Commentaires   
Commentaire de Dalila Belkebir [ 17/nov./08 18:27 ]
OK alors il y a 2 fichiers comportant chacun environ 20 000 paniers.
Donc :
=> on est loin des 5 x 2000 paniers à extraire prévu initialement dans le JIRA http://pricejira/browse/BIN-505
=> lequel des fichiers dois-je prendre en compte ?

Merci.

Dalila.
Commentaire de Mathieu Richomme [ 17/nov./08 18:53 ]
Export_DI20081107-bis.xls

5 onglets de 2000 lignes

merci
Commentaire de Dalila Belkebir [ 18/nov./08 12:41 ]
Mathieu,

J'ai généré 4 000 extractions à partir des 2 000 ALL et 2 000 LS hors marque.
J'ai pour cela utilisé les mêmes infos que celles indiquées dans le rapport Purchase tracking by month (cf JIRA 505).

Le fichier est disponible sur le serveur ALL et dans le répertoire :
T:\BI\01 - Demandes ponctuelles\demandes GGR tracking extract pr etude avec DI\extraction du 17 11 2008

Peux-tu STP me valider que ce sont les bonnes infos que vous attendez ?
Auquel cas je continue les autres extractions. Sinon, donne moi plus de précisions.
Merci.

Je passe te voir pour aller plus vite.

Cordialement,
Dalila.
Commentaire de Dalila Belkebir [ 18/nov./08 18:24 ]
Mathieu,

C'est fait.
Tu trouveras le résultat dans le répertoire BI du serveur All ou attaché au JIRA.

Cordialement,
Dalila.
Commentaire de Mathieu Richomme [ 19/nov./08 10:59 ]
parfait
Merci Dalila!




[EXP-3566] BI : impossibilité d'arrêter la plateforme de Production?!!! Création: 09/mai/07 18:35  Mise à jour: 25/juin/07 19:01  Résolue: 22/juin/07 14:48

Etat: Fermé
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Il semblerait que nous n'ayons pas le droit d'arrêter nos services BusinessObjects sur tellus parce que cela génère des alertes auprès de l'équipe d'exploitation et de notre hébergeur?!!!
Nous aimerions bloqué l'accès à notre application aux utilisateurs. Arrêter notre application nous semblait une bonne solution, mais bon...

Dépité, nous nous disons que, dans ce cas, l'URL d'accès bi pourrait être redirigé vers une page de maintenance, mais ce n'est pas possible non plus?!

Que pouvons nous donc faire pour interdire l'accès à notre application aux utilisateurs lors des phases de maintenance?

Merci:-)

Agathe

 Commentaires   
Commentaire de Antoine Koener [ 10/mai/07 16:40 ]

Agathe, on va regarder cela de plus près, en attendant, la phase de maintenance dure combien de temps ?
Quel est le risque réél ?
Ma question nous permettra de déterminer la solution la plus appropriée, afin de rapidement mettre quelquechose en place :)


Commentaire de Agathe Remy [ 10/mai/07 17:02 ]
La maintenance est à présent terminée.

Pour la petite histoire, nous avons fait une mise en production la semaine dernière et, en raison du plantage du SAN vendredi, nous n'avons pas pu finir de la tester:-( Notre alimentation a donc planté dans la nuit de vendredi à samedi:-(((

Hier, nous avions donc 4 jours d'alimentation à rattraper. Nous avons donc voulu couper l'accès à notre application BI afin d'empêcher nos utilisateurs de faire des requêtes sur notre Datawarehouse alors que nous étions en train de le mettre à jour.
L'objectif était à la fois d'éviter qu'ils se retrouvent avec des données incohérentes et de faire en sorte que leurs actions ne pénalise pas le rattrapage en surchageant la base pour rien.

Les risques réels sont donc :
- pour l'utilisateur, d'avoir des données incohérentes ou simplement fausses
- pour nous, d'avoir des problèmes de temps de chargement dus aux requêtes des utilisateurs

Est-ce que cela répond à ta question?

Agathe




Commentaire de Antoine Koener [ 11/mai/07 10:18 ]

Absolument.

Est-ce que déjà tu aurais une idée de comment faire simplement ?
Est-ce que de bloquer l'accès au site te semble suffisant ?

Est-ce que vous voulez être indépendants sur ces mises en maintenance ou bien aller vous passer par un interlocuteur de notre équipe ?
Commentaire de Antoine Koener [ 11/mai/07 15:28 ]

Il faut décider de la méthode à mettre en place, ensuite savoir si JET serait ok ne mettre un nouveau script exécutable par sudo...

Qu'en penses-tu ?
Commentaire de Patrice Boulanger [ 11/mai/07 16:58 ]
Je suggére de ne pas passer par Jet. Actuellement, il y a une rewrite.rules qui redirige:

RewriteCond %{HTTP_HOST} ^bi.*
RewriteRule ^/$ http://bi.priceminister.com/businessobjects/enterprise115/ [L,R]

On en ajoute une qui sera commentée, et qui redirige vers un maintenance.asis.

On fera l'opération manuellement comme ça on sera prévenu du début et de la fin de la maintenance.
Commentaire de Antoine Koener [ 14/mai/07 11:21 ]
Jérémie peux-tu s'il te plait t'occuper d'ajouter un commentaire dans les fichiers de rewrite nous permettant de rapidement trouver la règle à commenter pour mettre le BI en maintenance ?

Une fois cela fait pourrais-tu mettre à jour ton wiki pour refléter cette modification ?

Merci
Commentaire de Jérémie Bennejean [ 15/mai/07 14:43 ]
Voila ce que j'ai ajouté à la fin du fichier du rr.V900

#REGLE POUR MAINTENANCE BI UNIQUEMENT
#RewriteCond %{HTTP_HOST} ^bi.*
#RewriteRule ^/$ http://bi.priceminister.com/bi.maintenance.asis [L,R]

Pour mettre le bi en maintenance il faudra commenter la règle existante:
RewriteCond %{HTTP_HOST} ^bi.*
RewriteRule ^/$ http://bi.priceminister.com/businessobjects/enterprise115/ [L,R]

Et décommenter la nouvelle.

Cela vous convient?
Commentaire de Jérémie Bennejean [ 15/mai/07 14:45 ]
Il s'agit du rr.V900 se trouvant ds le rep production.
Commentaire de Patrice Boulanger [ 16/mai/07 15:54 ]
Comme vu avec Jérémie, cette solution ne marche pas car le JkMount du VH bi redirige toutes les servlet vers le tomcat sur tellus. On peut donc changer la redirection en:

#REGLE POUR MAINTENANCE BI UNIQUEMENT
#RewriteCond %{HTTP_HOST} ^bi.*
#RewriteRule ^/$ http://www.priceminister.com/bi.maintenance.asis [L,R]

Et créer une page spécifique pour ce site.

Merci.

Commentaire de Jérémie Bennejean [ 16/mai/07 16:09 ]
C'est fait, quand pouvons-nous faire un test ?
Commentaire de Jérémie Bennejean [ 28/mai/07 11:19 ]
Vu avec Agathe pour le 18 juin.
Commentaire de Jérémie Bennejean [ 22/juin/07 14:48 ]
La regle de redirection est en place.
Nous l'activerons à la demande d'Agathe.




Finalisation installation de BO en PROD (EXP-772)

[EXP-773] Redirection de bi.priceminister.com Création: 04/janv./06 17:47  Mise à jour: 25/juin/07 18:55  Résolue: 05/janv./06 15:08

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Sébastien Tournay Attribution: Ranto Andriambololona
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Rediriger l'URL http://bi.priceminister.com vers http://bi.priceminister.com/businessobjects/enterprise11/desktoplaunch/InfoView/logon/logon.do pour arriver directement sur l'applicatif BI et éviter de prendre les pages par défaut TOMCAT/APACHE

 Commentaires   
Commentaire de Ranto Andriambololona [ 05/janv./06 15:08 ]
C'est fait ...

Pour tester il faut cliquer sur http://bi.priceminister.com/




[EXP-3189] BI Espagne : besoin de créer le user BABEL_BI sur la base Espagne Création: 25/janv./07 11:18  Mise à jour: 25/juin/07 19:00  Résolue: 01/févr./07 12:19

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Bloquant
Rapporteur: Agathe Remy Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Serait-il possible de mettre en place le user BABEL_BI avec les synonymes privés sur toutes les tables en Espagne en Integ et en Prod?

Merci:-)

Agathe

 Commentaires   
Commentaire de Antoine Koener [ 25/janv./07 17:13 ]
Est-ce possible ?
Commentaire de Patrick Pereira [ 26/janv./07 14:02 ]
Fait en integ.
Commentaire de Patrick Pereira [ 26/janv./07 14:06 ]
En plus droits pour le user BABEL_BI pour exécuter les fonctions Toeuro() et toeuro2()
Commentaire de Patrick Pereira [ 01/févr./07 12:19 ]
Fait en prod.




[BIN-469] [BI Import] : Mise en place reporting / BI Data_file Création: 24/juil./08 16:30  Mise à jour: 13/nov./08 19:09  Résolue: 13/nov./08 19:09

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Justin Ziegler Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File STATISTIQUES IMPORT.rar    
Pays:
FRA - France

 Description   
L'intégrale en un seul épisode :

Il s'agit d'un projet qui se veut "Quick win techno driven" pour l'équipe commerciale, par le biais de l'équipe param / import.

L'idée est de ne prendre que la table data_file dans l'alim. Celle-ci contient déjà plusieurs dénormalisation / stat issus de la table data_line. Il faudra aussi prendre les tables de code voisines : type de fichier, status... Il faut prendre cette table de façon incrémentale.

Les rapports intéressants au niveau fichier :

1/ Evolution du nb de partenaire utilisant le système d'import. Soit le nb de partenaire distinct présent dans la table data_file par mois, par jour. On souhaite suivre la croissance de cette info. Un graphe serait sympa.

2/ Evolution du nb de fichiers arrivés dans le système d'import, par type de fichier et tous types de fichier confondus. Soit le nb de ligne présent dans la table data_file par mois, par jour. On souhaite suivre la croissance de cette info. Un graphe serait sympa.

3/ Le focus sur un partenaire précis doit être possible : évolution nb de fichier & nb de ligne sur une période.

4/ Hit parade (top 100 par ex) des plus gros utilisateurs du système d'import (sur les n derniers jour ?) : en nb de ligne (par mois / par jour) et en nb de fichier.

5/ Le meme que le précédent mais en ordre inverse. Objectif : détecter ceux qui faisaient des imports réguliers et qui soudainement n'en font plus.


Les rapports intéressants au niveau ligne :

1/ Evolution dans le temps (jour / mois) du nombre de lignes traitées, taux de réussite, par type de fichier / type de traitement. Temps de traitement moyen d'une ligne si possible.

2/ Evolution dans le temps (jour / mois) du nb d'annonce (de produit) crée / mis à jour / supprimé

3/ top 20 identifiant les partenaires dont le temps de traitement moyen de la ligne est le plus long.


Début d'idées pour les statistiques souhaitées pour Frédéric :
- Avoir des statistiques de délais (délais de traitement, délais d'attente, durée de vie d'un import)
- Définir des statistiques sur le type de traitement utilisé (création annonces, mise à jour produits, etc..)
- Lister tous les login n'utilisant pas les imports depuis X temps

- Lister les profils ou les format non utilisés [[ ATTENTION : rester sur data_file dans un premier temps]]

- Faire un rapprochement entre le taux de succès des imports et le chiffre d'affaire du partenaire (afin de pouvoir prioriser l'optimisation des Imports) [[ ATTENTION : rester sur data_file dans un premier temps]]

Dans un deuxième temps :
- rapprochement avec d'autres info : ventes, annulation


 Commentaires   
Commentaire de Dalila Belkebir [ 24/juil./08 17:26 ]
L'épisode 2 :
Scénariste Frédéric
Acteurs : Frédéric et Dalila.

Voici un petit résumé sur la présentation des Imports à Dalila:
- Présentation du métiers Import
- Présentation des outils Imports (BO, format, profil, fichiers, FTP)
- Présentation des statiques réalisées par rapport à nos outils (TABLE DATA_FILE) (voir fichier ci-joint) :

1/ Statistiques sur les partenaires utilisant les Imports (Comparatif par rapport aux années précédentes)
2/ Statistiques sur les fichiers soumis (Comparatif par rapport aux années précédentes)
3/ Statistiques sur le nombre de lignes traitées (Comparatif par rapport aux années précédentes)
4/ Statistiques sur le taux de réussite des imports (Comparatif par rapport aux années précédentes)
Statistiques sur l'evolutions des courbes 1,2,3,4 (depuis 2005 à nos jours)

L'idéale serait de bénéficier de ses stats automatiquement et dynamiquement, comme par exemple avoir la les courbes Import pour un login en particulier, etc ...

=> Début d'idées pour les statistiques souhaitées pour ma part :
- Avoir des statistiques de délais (délais de traitement, délais d'attente, durée de vie d'un import)
- Définir des statistiques sur le type de traitement utilisé (création annonces, mise à jour produits, etc..)
- Lister tous les login n'utilisant pas les imports depuis X temps
- Lister les profils ou les format non utilisés
- Faire un rapprochement entre le taux de succès des imports et le chiffre d'affaire du partenaire (afin de pouvoir prioriser l'optimisation des Imports)
Etc....

 
Cordialement
Frédéric NAHUM
Responsable Pôle Import
Tel : 01.42.78.79.80

Commentaire de Dalila Belkebir [ 24/juil./08 17:29 ]
Statistiques d'import de Frédéric NAHUM
Commentaire de Dalila Belkebir [ 13/nov./08 19:09 ]
Bonjour,

Le projet est livré en production.
Un lot 2 est déjà planifié sur 2009 pour prendre en compte des évolutions "qualitatives" suite à l'analyse des données mises à disposition.


Merci à tous de votre participation, et tout particulièrement à l'équipe BI.

Cordialement,
Dalila.




[BIN-103] problème BI Création: 07/juin/06 15:39  Mise à jour: 14/sept./07 17:02  Résolue: 07/juin/06 16:53

Etat: Fermé
Projet: Business Intelligence
Composants: Bug & Improvement
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Elodie Pasquale Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures


 Description   
BI ne marche toujours pas pour recall/new buyers after mailing

jai une fenêtre d'erreur qui s'ouvre
WIS 00005 Error INF

Elodie
elodie.pasquale@priceminister.com
Tel : +33 (0)1 42 78 87 15


 Commentaires   
Commentaire de Samir Beghdadi [ 07/juin/06 16:53 ]
C'est bon le problème est réglé après avoir modifié le chemin de l'objet Purchase display month pour le filtre Select authorization month period.




[INF-64] Demande d'accès aux emails et aux interfaces de supervision BI depuis chez moi Création: 22/mai/08 17:03  Mise à jour: 05/nov./08 16:46  Résolue: 05/nov./08 16:46

Etat: Résolu
Projet: Infrastructure
Composants: Micro
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Ange Ferrari
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Bonjour,

L'idée est que je puisse vérifier le bon fonctionnement des alimentations BI (et éventuellement les relancer) depuis chez moi.
Pour cela, la solution semble de remplacer mon PC par un portable pas trop lourd parce que je suis petite, mais pas trop cher, avec un station de travail et un sac à dos?
Il me faut au moins 1Go de RAM sous Windows XP pour pouvoir exécuter les outils BI et 40 Go d'espace disque pour les installer.
Les accès nécessaires sont :
- accès à la messagerie
- accès aux serveurs de Production en ssh (latone, tellus)
- accès à bi.priceminister.com
- accès à Oracle Entreprise Manager : http://latone.lan:5500/em/, http://latone.lan:5501/em/, http://latone.lan:5502/em/
et éventuellement : https://supervision.priceminister.jmh:11000/

Pour info, je dispose chez moi d'une connexion free.

J'espère que je n'ai rien oublié et reste à votre disposition pour répondre aux questions.

Merci.

Agathe


 Commentaires   
Commentaire de Justin Ziegler [ 22/mai/08 17:12 ]
Pourrait on en profiter pour migrer Agathe en imap ?
Commentaire de Agathe Remy [ 09/juin/08 11:10 ]
Bonjour,

J'ai terminé l'installation des outils BI sur le portable. Tout semble bien fonctionner:-)

Etape suivante : l'accès à distance...

Merci.

Agathe
Commentaire de Stéphane Eccli [ 09/juin/08 11:29 ]
repasse moi le ticket apres ouverture du VPN
Commentaire de Agathe Remy [ 10/juin/08 10:06 ]
Voici mon IP fixe :
81.56.56.49

Agathe
Commentaire de Ange Ferrari [ 12/juin/08 09:46 ]
Pour l'accès à la supervision

https://supervision.priceminister.com:11000/

avec ton login et mdp habituel

pour le reste je te tiens au courant au fur et à mesure de l'avancée des choses
Commentaire de Ange Ferrari [ 12/juin/08 11:40 ]
pour bi.priceminister.com
c'est en place
Commentaire de Ange Ferrari [ 20/juin/08 14:01 ]
JET a procédé à l'ouverture du flux ssh
peux tu valider le fonctionnement ?
Commentaire de Agathe Remy [ 08/juil./08 09:55 ]
ça marche trop bien!!!

A part en wifi où ça coupe tout le temps... Mais avec un cable réseau, j'ai réussi depuis chez moi à me connecter :
- aux serveurs de Production en ssh (latone, tellus) via phaeton.priceminister.com
- à bi.priceminister.com en créant un tunnel sur tellus
- à Oracle Entreprise Manager : http://latone.lan:5500/em/, http://latone.lan:5501/em/, http://latone.lan:5502/em/ en créant un tunnel sur latone

J'ai oublié de vérifier l'accès à la supervision : https://supervision.priceminister.jmh:11000/ ?!

Ne me manque plus que l'accès à la messagerie!

Merci et j'attends vos nouvelles pour le dernier point.

Agathe
Commentaire de Agathe Remy [ 02/oct./08 10:37 ]
Bonjour,
Je n'arrive plus à accéder à BusinessObjects en Production (bi.priceminister.com).
Peut-être est-ce lié à la migration du serveur BO sur elasippos.
S'il vous plait, pouvez-vous regarder ce qu'il en est?
Merci.
Agathe
Commentaire de Agathe Remy [ 05/nov./08 16:44 ]
Bonjour,

Suite aux modifs de la semaine dernière, j'ai testé mes accès BI ce week-end (02/11/2008) et cela fonctionne parfaitement.
Merci!
Vous pouvez clôturer le JIRA.

Agathe




[EXP-1928] Plus d'accès à http://bi.pm.lan Création: 03/mai/06 15:35  Mise à jour: 25/juin/07 18:57  Résolue: 04/mai/06 11:20

Etat: Résolu
Projet: Exploitation
Composants: Troubleshooting
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Bloquant
Rapporteur: Agathe Remy Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 5 minutes
Estimation originale: Non spécifié


 Description   
Tout à coup, nous n'avons plus d'accès à l'url suivante:
http://bi.pm.lan
Pour info, il est 15h35 le 03/05/2006...

 Commentaires   
Commentaire de Sébastien Tournay [ 04/mai/06 10:40 ]
En tout cas ce matin cela marche ... Jérémie vous avez fait quelque chose ? Agathe, vous étiez en train de redémarrer votre application ?
Commentaire de Jérémie Bennejean [ 04/mai/06 11:20 ]
Quand le site est passé en maintenance, tout la conf apache pointe sur un rep maintenance.
Dans ce répertoire il y a un ficher de rewrite rules, qui indique à apache que les pages vers bi ne sont pas redirigées vers la page de maintenance.
Or avant hier bi n'étais pas redirigé vers la page de maintenance, d'ou l'affichage d'une page "erreur page non trouvée"




[BIN-608] [FINANCE] écart entre les chiffres de VA Titan et BI Création: 08/juil./09 17:06  Mise à jour: 17/août/09 15:33  Résolue: 09/juil./09 15:30

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Matthieu Azema Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel 200906 - Ecarts GMS capturé.xls    
Liens des demandes:
Similaire
similaire à APP-25890 Pb de batch capture : les frais de po... Fermé
Pays:
FRA - France

 Description   
Dans le rapport BI Financial/Confidential/ "Purchase summary by month", le montant qui ressort pour le mois de juin en "Captured gross merchandized sold" est de 8930648.73.
Dans le rapport Titan "Commission breakdown", la somme des colonnes "Val Art" + "Total FPA" + "Total Garanties TTC" (avec un filtre sur la période de juin 2009) est censé nous donné le même montant que celui issu du BI (cf ci-dessus). Hors pour juin, il ressort un montant de 8931680.21 soit un écart de 1031.48

Merci
Matthieu

 Commentaires   
Commentaire de Agathe Remy [ 09/juil./09 15:30 ]
Bonjour Mathieu,

Je viens de vérifier : les chiffres sont identiques entre terra et BI (normalement de GMS du rapport BI "Purchase summary by month" est comparé aux montants du rapport terra "paniers_coupons_articles".
L'écart provient d'une différence que nous ne savons pas expliquer entre le montant réellement capturé (débité l'acheteur) et celui qui aurait du l'être.
Nous avons ainsi identifié 52 paniers autorisés entre les 16 et 18/06 (capturés entre les 18 et 24/06) constituant cet écart de 1031.48¿.

Il s'agit donc d'un incident sur le site.
Si tu as besoin d'en savoir plus, je t'invite donc à ouvrir un bug auprès des équipes Développement.

Agathe
Commentaire de Agathe Remy [ 09/juil./09 15:55 ]
Vous trouverez ci-joint les 52 paniers qui expliquent cet écart :
- l'un est une erreur de capture manuelle
- les 51 autres restent inexpliqués

Agathe
Commentaire de Christophe Garcia [ 09/juil./09 16:35 ]
Ca sent la modif de frais de port (shipping size 1540) ....

2009-06-18 19:23:22,990 INFO [10.150.28.77] CAPTURE - Purchase Id : 72503236
2009-06-18 19:23:23,007 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R1 mode for the shipping size 1540
2009-06-18 19:23:23,013 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R1 mode for the shipping size 1540
--
2009-06-18 20:07:32,971 INFO [10.150.28.77] CAPTURE - Purchase Id : 72471229
2009-06-18 20:07:32,985 INFO [10.150.28.77] REQUEST - Processed: 35 (REQUESTED: 35)
2009-06-18 20:07:32,990 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 20:07:32,994 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
--
2009-06-18 20:09:49,155 INFO [10.150.28.77] CAPTURE - Purchase Id : 72489036
2009-06-18 20:09:49,173 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R1 mode for the shipping size 1540
2009-06-18 20:09:49,178 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R1 mode for the shipping size 1540
--
2009-06-18 20:59:39,058 INFO [10.150.28.77] CAPTURE - Purchase Id : 72470161
2009-06-18 20:59:39,080 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 20:59:39,089 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
--
2009-06-18 22:42:12,047 INFO [10.150.28.77] CAPTURE - Purchase Id : 72484708
2009-06-18 22:42:12,063 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 22:42:12,068 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
--
2009-06-18 22:44:18,067 INFO [10.150.28.77] CAPTURE - Purchase Id : 72498824
2009-06-18 22:44:18,089 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R2 mode for the shipping size 1540
2009-06-18 22:44:18,109 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Recommandé R2 mode for the shipping size 1540
--
2009-06-18 23:28:29,117 INFO [10.150.28.77] CAPTURE - Purchase Id : 72428578
2009-06-18 23:28:29,132 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 23:28:29,137 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 23:28:29,153 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 23:28:29,156 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
--
2009-06-18 23:28:33,928 INFO [10.150.28.77] CAPTURE - Purchase Id : 72440146
2009-06-18 23:28:33,950 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 23:28:33,955 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
--
2009-06-18 23:28:44,431 INFO [10.150.28.77] CAPTURE - Purchase Id : 72445974
2009-06-18 23:28:44,452 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 23:28:44,457 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 23:28:44,479 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 23:28:44,483 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
--
2009-06-18 23:28:50,778 INFO [10.150.28.77] CAPTURE - Purchase Id : 72448855
2009-06-18 23:28:50,796 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540
2009-06-18 23:28:50,801 ERROR [10.150.28.77] CAPTURE - SHIPPING : No shipping pricing was found in Normal mode for the shipping size 1540




[APP-26299] [Migration CBV] Créer une vue pour éviter des impacts au BI Création: 27/août/09 14:57  Mise à jour: 21/sept./09 11:14  Résolue: 28/août/09 10:36

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 53.0.0 (TX-I)
Version(s) corrigée(s): 53.0.0 (TX-I)

Type: Tâche Priorité: Majeur
Rapporteur: Arnaud Forgues Attribution: Arnaud Forgues
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Dépendance
bloque APP-25955 [Post Extensions de garantie] Adaptat... Fermé
Pays:
FRA - France
Projets PM archivés: Extensions de garanties (Lot 1) : Articles neufs

 Description   
Lors de la migration CBV permettant de synchroniser le système de configuration du CBV avec celui des EG, on a modifié la notion de type de garantie de la manière suivante :
- type CBV_INTERNAL (20) ==> type CBV (40) + flag is_external_managed = 0
- type CBV_EXTERNAL (10) ==> type CBV (40) + flag is_external_managed = 1

Cette modification ayant des impacts non négligeable en terme de timing pour l'équipe BI, l'idée est de créer une vue pour maintenir l'ancienne modélisation.

On modifiera alors le synonyme "babel_bi.warranty" en le faisant pointer vers la nouvelle vue !

 Commentaires   
Commentaire de Arnaud Forgues [ 28/août/09 10:36 ]
Une nouvelle vue "warranty" vient donc remplacer l'ancien synonym "warranty" qui pointait vers "purchase_1.warranty". Le script est à passer en POST DEPLOY le jour même du déploiement

Il se trouve ici : V:\Database\TX-I\integ\TX-I_MIGRATION_CBV_14_FR_create_view_for_bi.sql




[INF-462] [BI] : Arrivée de 2 stagiaires BI le 10/05/2010 Création: 23/avr./10 16:32  Mise à jour: 10/mai/10 14:29  Résolue: 10/mai/10 14:29

Etat: Résolu
Projet: Infrastructure
Composants: Arrivée/Départ
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Christophe Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word FICHE NOUVEL ARRIVANT FLL.doc     Microsoft Word FICHE NOUVEL ARRIVANT MFB.doc    

 Description   
Bonjour,

2 stagiaire de fin d'étude BI arrive le 10/05/2010 pour 6 mois : Fabrice LIMA LOPES (FLL) et Meriam Fatima BOUAICHA (MFB)
Toutes les infos sont dans les fiches nouvel arrivant ci-jointes.

A ta dispo si tu as besoin d'autres infos.

Merci,

Agathe

 Commentaires   
Commentaire de Agathe Remy [ 06/mai/10 11:53 ]
Bonjour Stéphane,

Stp, est-ce que tu pourras également ajouter leurs emails à l'alias biteam@priceminister.com?

Merci,
Agathe
Commentaire de Stéphane Eccli [ 07/mai/10 16:23 ]
comptes créés reste jira
Commentaire de Christophe Garcia [ 10/mai/10 12:32 ]
J'ai besoin de leurs 2 adresses mails.

Merci
Commentaire de Stéphane Eccli [ 10/mai/10 12:35 ]
fabrice.lima-lopes@priceminister.com
meriam-fatima.bouaicha@priceminister.com




[EXP-4635] [ BI UK ] Création des instances BDD pour BI UK Création: 04/déc./08 15:48  Mise à jour: 17/déc./08 11:15  Résolue: 17/déc./08 11:05

Etat: Résolu
Projet: Exploitation
Composants: Evolution
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Bloquant
Rapporteur: Dalila Belkebir Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
GBR - Royaume Uni

 Description   
Bonjour Patrick,

Dans le but de démarrer les devs du projet BI UK nous avons besoin que tu nous créées :

1 - Création sur la base DW DEV : Pommery
Schéma // Tablespace
ODS_UK /// ODS_UK et ODS_UK_IX
DWH_UK /// DWH_UK et DWH_UK_IX
DTM_UK /// DTM_UK et DTM_UK_IX
RT_UK /// RT_UK et RT_UK_IX

2 - Création sur la base DW PRD : Latone
Schéma // Tablespace
ODS_UK /// ODS_UK et ODS_UK_IX
DWH_UK /// DWH_UK et DWH_UK_IX
DTM_UK /// DTM_UK et DTM_UK_IX
RT_UK /// RT_UK et RT_UK_IX

Donc pour chaque environnement :
4 schémas :
            ODS_UK
            DWH_UK
            DTM_UK
            RT_UK
Avec 2 tablespaces par schéma, l'un portant le même nom que le schéma (pour les tables), l'autre avec l'extension _IX pour les indexes.

Il nous faut ces environnements pour :
DEV : dès que possible afin de démarrer les devs (les spécifications étant quasi finies).
PROD : 02/01/2009

N'hésite pas à nous contacter si tu as besoin de plus d'informations.
Merci de ton retour.
Dalila.

 Commentaires   
Commentaire de Patrick Pereira [ 09/déc./08 11:11 ]
Les tablespaces et users ont été créés en dev (password = login).
Je transmets la demande à Didier B. pour la prod.
Commentaire de Patrick Pereira [ 09/déc./08 11:24 ]
Ticket 6438 créé chez Jet
Commentaire de Agathe Remy [ 09/déc./08 11:31 ]
Trop cool:-)

Merci!
Commentaire de Patrick Pereira [ 17/déc./08 11:05 ]
C'est fait en prod aussi.
Commentaire de Dalila Belkebir [ 17/déc./08 11:15 ]
OK, merci Patrick.

On vérifie et on te fait un retour.

dalila.




[BIN-177] BI Espagne : lot 1 Création: 13/oct./06 17:15  Mise à jour: 14/sept./07 17:22  Résolue: 13/août/07 18:41

Etat: Fermé
Projet: Business Intelligence
Composants: Sales
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Bloquant
Rapporteur: Agathe Remy Attribution: Agathe Remy
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Liens des demandes:
Dépendance
bloque BIN-323 Rapport Copie de CA par catégorie ne ... Fermé
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
BIN-178 Creation des schémas ODS_ES, DWH_ES e... Sub-new feature Fermé Patrick Pereira  
BIN-179 Implémentation de l'environnement OWB Sub-new feature Fermé Samir Beghdadi  
BIN-180 Implémentation de l'environnement BO Sub-new feature Fermé Agathe Remy  
BIN-181 Mise à jour du modèle de données Sub-new feature Fermé Agathe Remy  
BIN-182 Déploiement de l'alimentation de l'ODS Sub-new feature Fermé Agathe Remy  
BIN-183 Déploiement de l'alimentation de DTM Sub-new feature Fermé Samir Beghdadi  
BIN-184 Déploiement des univers Sub-new feature Fermé Samir Beghdadi  
BIN-185 Déploiement des rapports Sub-new feature Fermé Samir Beghdadi  
BIN-186 Tests de données Sub-new feature Fermé Agathe Remy  
BIN-187 Tests d'implémentation Sub-new feature Fermé Agathe Remy  
BIN-188 Création des schémas de données en Pr... Sub-new feature Fermé Patrice Boulanger  
BIN-189 Passage en production du modèle de do... Sub-new feature Fermé Agathe Remy  
BIN-190 Passage en production de l'alimentation Sub-new feature Fermé Agathe Remy  
BIN-191 Passage en production des univers et ... Sub-new feature Fermé Samir Beghdadi  
BIN-192 Initialisation du Datamart Sub-new feature Fermé Samir Beghdadi  
BIN-279 Création et alimentation de l'agregat... Sub-bug Fermé Agathe Remy  
BIN-280 Spécifications techniques et développ... Sub-bug Fermé Samir Beghdadi  
BIN-281 Extractions mensuelle et quotidienne 4D Sub-bug Fermé Agathe Remy  
Pays:
ESP - Espagne

 Description   
Mise en place du lot 1 BI Espagne




[INF-192] BI bloqué sur ma machine Création: 03/nov./08 10:26  Mise à jour: 04/nov./08 11:20  Résolue: 04/nov./08 11:20

Etat: Résolu
Projet: Infrastructure
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Mathieu Richomme Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Bonjour Stéphane,

vu avec Agathe ce matin il faudrait désinstaller un composant Java pour que mes rapports BI puissent tourner

d'avance merci pour ton aide,
Mathieu

 Commentaires   
Commentaire de Stéphane Eccli [ 04/nov./08 11:20 ]
ok




[INF-293] BI : Arrivée de Geoffroy le 06/04/2009 Création: 25/mars/09 18:12  Mise à jour: 04/mai/09 16:25  Résolue: 04/mai/09 16:25

Etat: Résolu
Projet: Infrastructure
Composants: Arrivée/Départ
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Christophe Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word FICHE NOUVEL ARRIVANT GVI.doc    

 Description   
Bonjour,

Un stagiaire de fin d'étude BI arrive le 06/04/2009 pour 6 mois : Geoffroy VIGNERON (VGI)
Il prendra le poste de Florian AMBROSI qui termine son stage le 31/03/2009.
Toutes les autres infos sont dans la fiche nouvel arrivant ci-jointe.

A ta dispo si tu as besoin d'autres infos.

D'autre part, suite au changement de poste de Dalila, serait-il possible de réattribuer son ancien poste (ou équivalent) à Cyril pour remplacer son vieux Transtec et son écran qui s'éteint sans raison? Dans le package Office, il faut qu'il ait PowerPoint notamment pour les formations BI.

Merci.

Agathe


 Commentaires   
Commentaire de Agathe Remy [ 25/mars/09 18:13 ]
Voici la fiche de nouvel arrivant!
Agathe
Commentaire de Agathe Remy [ 30/mars/09 18:33 ]
J'en profite également pour te demander de supprimer florian.ambrosi@priceminister.com de l'alias biteam@priceminister.com et de le remplacer par l'email de Geoffroy:-)

Merci!
Agathe
Commentaire de Stéphane Eccli [ 03/avr./09 11:51 ]
comptes ok, reste Jira




[BIN-700] Export BI Pros / Seo Création: 09/déc./10 11:25  Mise à jour: 22/déc./10 14:10  Résolue: 20/déc./10 12:18

Etat: Résolu
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Thierry Leforestier Attribution: Valéria Gusa
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Dans le cadre d'une étude, nous avons besoin d'un export du BI contenant les colonnes suivantes :

SELLER_LOGIN || PRODUCT_ID || CA AUTHORISED || CA CAPTURED

Pour les critères suivants :
Vendeurs pros uniquement
Produits vendus avec et sans stock, produits non vendus avec stock (oui.. c'est un peu tordu)
Période de vente : 30 jours précédant l'export (ou mois précédent)

N'hésitez pas si il y a besoin de plus de précisions.

 Commentaires   
Commentaire de Valéria Gusa [ 20/déc./10 12:16 ]
Les données ont été extraites dans le fichier suivant : /data/priceminister/pmshare/tle/

Valeria.
Commentaire de Valéria Gusa [ 20/déc./10 12:17 ]
Pardon, j'ai oublié le nom du fichier : ExtractBI_SEO.csv

Valeria
Commentaire de Thierry Leforestier [ 22/déc./10 14:10 ]
Merci c'est top, on va pouvoir analyser ça tranquillement, je vous tiens au courant.

Thierry




[BIN-624] [FINANCE] : Ecart GMS capturé juillet 2009 entre Titan et BI Création: 12/août/09 12:13  Mise à jour: 30/sept./09 17:23  Résolue: 07/sept./09 12:28

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Matthieu Azema Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel aout_cancelled_items_bug_warranties.xls     Microsoft Excel cancelled_items_bug_warranties.xls    
Liens des demandes:
Similaire
similaire à APP-26025 panier 100% annulé - on capture le cb... Fermé
Pays:
FRA - France

 Description   
Dans le rapport BI Financial/Confidential/ "Purchase summary by month", le montant qui ressort pour le mois de juin en "Captured gross merchandized sold" est de 8852276.47
> Dans le rapport Titan "Commission breakdown", la somme des colonnes
> "Val Art" + "Total FPA" + "Total Garanties TTC" +"Total EG TTC" (avec un filtre sur la
> période de juillet 2009) est censé nous donné le même montant que celui
> issu du BI (cf ci-dessus). Hors pour juillet, il ressort un montant de
> 8856292.93 soit un écart de 4016.46
Merci
Matthieu


 Commentaires   
Commentaire de Agathe Remy [ 17/août/09 11:33 ]
Bonjour Matthieu,

Comme la dernière fois, l'écart ne se situe pas entre BI et Titan, mais entre les décompositions article et panier : tu peux constater le même écart en comparant les rapports BI "Purchase summary by month" et "Commission breakdown by month".
En effet, il est du à un bug dév lors de la MEP des EG : des garanties ont été capturées sur des paniers annulés (cf JIRA APP-26025).

Agathe
Commentaire de Matthieu Azema [ 17/août/09 11:44 ]
Bonjour Agathe,

Effectivement, cet écart a bien été identifié. Malheureusement, ce n'est pas le seul. Après investigations, il semblerait que le rapport Titan comptabilise 2 fois la capture de la valeur article et des frais de port associés et ce, uniquement lorsque l'acheteur a souscrit à la fois à la garantie CBV et à L'EG.

Matthieu
Commentaire de Julien Girardet [ 07/sept./09 12:28 ]
Bonjour Matthieu,

Les rapports Terra sont corrigés. Pour les rapports BI, c'est en cours de correction.

Julien.
Commentaire de Julien Girardet [ 14/sept./09 12:14 ]
Bonjour Mathieu,

Une fois le rapport TERRA "Commission breakdown" corrigé (livré la semaine derniere), il existe encore un écart avec le rapport BI "Purchase summary by month"
En effet pour le mois de Juillet :
Rapport "Commission breakdown" TERRA : la somme des colonnes "Val Art" + "Total FPA" + "Total Garanties TTC" +"Total EG TTC" = 8848169,02
Rapport "Purchase summary by month" : Captured gross merchandized sold : 8852276,47
Donc il existe un écart de 4107.45

Cet écart provient des montants garanties capturés à tord sur des articles annulés au mois de Juillet (voir bug cbv)

Voici le listing des articles concernés par cet écart.
La somme des montants garanties (CBV+ EG) de ces articles correspond à l'écart : 4107.45

A ta disposition pour plus d'informations.

Julien.
Commentaire de Julien Girardet [ 14/sept./09 18:37 ]
Mail de Philippe :

Bonjour Julien,

Merci pour les modifications apportées aux rapports Titan "panier coupon article" et "commission breakdown".
Pour le mois de juillet ne subsiste donc plus effectivement que l'écart de 4
107,45 euros que tu mentionnes ci-dessous (et qui est expliqué).

Sur août on a également un petit écart de 1,23 euros entre :
- le VA ressortant du commission breakdown de Titan et ;
- le VA du "panier coupon article" de Titan / le VA du "purchase summary by month" de BO.
Matthieu va investiguer pour essayer de comprendre ce dont il s'agit ; si besoin on te sollicitera.

Merci
Philippe

--------------------------------

Reponse :

Bonjour Philippe,

Cet ecart provient également du bug CBV, j'ai executé la meme requete pour lister les articles "victimes" de ce bug sur le mois d'Aout, et je trouve 2 articles !
Et bien sur la somme des garanties correpond à l'ecart : 1,23
Je ne pensais pas que le bug était encore present sur le mois d'aout...

Ci joint le listing des articles concernés sur le mois d'aout.

Julien

Commentaire de Dalila Belkebir [ 30/sept./09 13:45 ]
Bonjour Philippe,

Pourrais-tu STP nous valider ce JIRA pour clôture ?
Merci d'avance,

cdlt,
Dalila.
Commentaire de philippe favrot [ 30/sept./09 17:19 ]
Dalila,
je te confirme que tu peux clôturer ce Jira.
Merci à Julien pour tout ce travail de réconciliation
Philippe




[BIN-298] [Transverse] : Migration du Dashboard vers le BI Création: 28/févr./07 10:02  Mise à jour: 17/sept./10 17:58

Etat: Ouvert
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Quentin de Chivré Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
ALL - Tous

 Description   
Le tableau de bord en BO devra être supprimé le jour ou tous les blocs (1 2 3 et 4, voir copie d'ecran) seront gérés par le BI.

Avantages :
- eviter de laisser acces a tout le monde a une info stratégique - c'est d'autant plus genant avec la croissance des effectifs de PM
- eviter une double maintenance - compteurs pas synchros entre les 2 outils qui engendrent des question de la part de Philippe / bugs qu'on laisse trainer coté BO applicatif / etc...
- eviter des calculs de données en Prod (tables ***_summary et batchs associés) qui sont consommateurs de ressources
- simplifier / rendre cohérente l'architecture de plateforme

Hier Agathe m'a montré un rapport qui (a priori) rend obsolete le bloc 4. Agathe, y a t'il des rapports correspondant aux autres zones ?
Quand tu pensera que l'on a un rapport pour chaque zone, je suggère que tu fasse faire un sondage rapide auprès des différents décideurs pour confirmer la suppression du dashboard et des courbes associées.

A ce moment, déplacer ce Jira côté Dev pour suppression du Dashboard. Que met t'on alors en HP du BO ? Bonne question, a voir avec Steven ? :-)

 Commentaires   
Commentaire de Justin Ziegler [ 28/févr./07 10:22 ]
attention, le rapport actuel d'Agathe ne traite que des 2 premieres colonnes de la zone 4 !
Commentaire de Agathe Remy [ 02/janv./08 11:30 ]
Romain,

Voici un sujet de réflexion si un jour tu as du temps?!

Agathe




[EXP-1953] BI : Backup Perignon Création: 04/mai/06 17:36  Mise à jour: 25/juin/07 18:57  Résolue: 18/mai/06 17:04

Etat: Résolu
Projet: Exploitation
Composants: Maintenance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: PDF File admin.pdf     PDF File deploying_webintelligence_applications.pdf     PDF File Install_unix_win_fr.pdf    

 Description   
Bonjour,

Suite au mail de Jérémie, et après en avoir discuté avec Justin, il s'avère que la sauvegarde des développements BusinessObjects sur Pérignon ne consiste pas en une simple copie de répertoire.
En effet, les développements sont stockés via un système de gestion de fichiers qui les versionne et les crypte.
Il faut donc faire une étude sur la meilleure façon de les sauvegarder : faut-il utiliser un utilitaire BusinessObjects? La simple copie des répertoires suffit-elle pour restorer l'application? Faut-il aussi sauvegarder un clé de cryptage? Et que sais-je encore...

Il s'agit d'une étude d'exploitation de l'outil BusinessObjects et il me semble que c'est à l'équipe Support de la mener.

Je vous joins donc la documentation d'administration de BusinessObjects XI, mais je pense qu'elle est insuffisante et qu'une investigation auprès de l'éditeur sera nécessaire.

Je reste à votre disposition pour toute question.

Cordialement,
Agathe

 Commentaires   
Commentaire de Sébastien Tournay [ 04/mai/06 17:43 ]
Pour l'instant l'équipe support c'est PAtrick et Edouard. On va donc demander à Edoaurd de creuser et valider ces aspects.
Commentaire de Justin Ziegler [ 04/mai/06 18:04 ]
Support ou pas, n'est ce pas un sujet pour Jeremy ?
Commentaire de Sébastien Tournay [ 04/mai/06 18:10 ]
Non. Si nous sommes sur une phase d'étude il me semble d'après ce que nous validons sur l'organisation que cela doit passer par l'équipe Support. Pour moi c'est un sujet pour Edouard. En plus on est sur des problématiques BDD+BI qui sont mieux maîtrisées par EDOUARD.

Ne refaisons pas ce que nous avons déjà fait en sous estimant le chantier sauvegarde.
Commentaire de Agathe Remy [ 11/mai/06 12:05 ]
Petite question : je pensais que l'équipe Support était celle qui s'occupait de l'expoitation des plateformes internes et de Production et que l'équipe Delivery était celle des études. Aurais-je mal compris?

Sinon, sur la sauvegarde des applis BI en interne :
- Les bases de données BI sont toutes situées sur Pommery et leur sauvegarde a déjà été mise en place par Edouard et Pap. Elle a été dernièrement validée par Jérémie.
- Il reste à mettre en place la sauvegarde des développements BusinessObjects situé sur Perignon. Après un parcours rapide des documentations jointes à ce JIRA et devant le manque de temps d'investiguer plus avant, je propose dans un premier temps de sauvegarder journalièrement l'intégralité de l'applicatif BusinessObjects, à savoir le répertoire /home/bo (3,3 Go) sur Perignon et tout ce qu'il contient. Après discussion aves Jérémie cette solution semble acceptable et rapide à mettre en place. Mais il est clair qu'elle n'est pas forcément la meilleure.

Sébastien, serais-tu d'accord dans ce cas de réattribuer ce JIRA à Jérémie afin que l'on cloture ce sujet avant le retour d'Edouard?

Merci:-)
Commentaire de Sébastien Tournay [ 11/mai/06 12:49 ]
oupss.. C'est effectivement le rôle des 2 équipes. J'ai du aller un peu vite.

Jérémie je te laisse terminer ce sujet. On pourrait l'inclure dans la boucle de sauvegarde de ce week-end.
Commentaire de Jérémie Bennejean [ 12/mai/06 18:10 ]
J'ai ajouter dans le scritp de sauvegarde le répertoire que désire Aghate "/home/bo" ( 3.3Go)
Une full quotidienne du repértoire sera ainsi faites.
Commentaire de Jérémie Bennejean [ 16/mai/06 10:55 ]
Mise en place sur LTO02




[EXP-2886] BI Espagne : environnement de développement Création: 24/oct./06 14:09  Mise à jour: 25/juin/07 18:59  Résolue: 27/oct./06 11:28

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Jérémie Bennejean
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
EXP-2898 J'en profite donc pour étoffer la dem... Sous-tâche Fermé Jérémie Bennejean  
Pays:
ESP - Espagne

 Description   
Bonjour,

Nous aimerions avoir une autre adresse IP avec un serveur name perignon_es sur perignon afin d'installer une deuxième instance de BusinessObjects.

Merci:-)

Agathe

 Commentaires   
Commentaire de Agathe Remy [ 25/oct./06 17:58 ]
C'est juste bloquant pour mon équipe pour avancer sur la mise en place du BI Espagne...

J'en profite donc pour étoffer la demande en ajoutant la mise en place d'une URL bi.es.dev

Merci:-)

Agathe
Commentaire de Jérémie Bennejean [ 26/oct./06 16:21 ]
cette @ est-elle temporaire comme dit au début ou souhaitez-vous la conserver ?
Commentaire de Jérémie Bennejean [ 26/oct./06 17:36 ]
Nous aimerions avoir une autre adresse IP avec un serveur name perignon_es sur perignon afin d'installer une deuxième instance de BusinessObjects.
--> C'est fait
192.168.1.14 perignon_es




[EXP-3018] BI : Migration BusinessObjects sur Tellus Création: 22/nov./06 14:48  Mise à jour: 16/avr./08 13:44  Résolue: 16/avr./08 13:44

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Patrice Boulanger
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
EXP-3363 Installer Redhast AS4 sur Brice Sous-tâche Résolu ZZ_Arnaud Baali  
EXP-3364 Installer la nouvelle version de BO s... Sous-tâche Résolu Patrice Boulanger  
EXP-3365 Préparer l'environnement sur Tellus (... Sous-tâche Résolu Patrice Boulanger  
Pays:
FRA - France

 Description   
Patrice,

Il faut prévoir une migration de tellus vers RedHat AS 4, puis de BusinessObjects Release 1 vers la Release 2.
Avant la migration, les étapes suivantes sont à prévoir :
- sauvgarde de BOREP (~2.5 Go) sur Latone
- création d'un nouveau schéma référentiel base de données sur l'instance BOREP de Latone
- sauvegarde des répertoires /home/bo/bobje/data/frsinput (~180Mo) et frsoutput (~49Mo)

Finalement, le plus tôt serait le mieux.

Merci:-)

Agathe


 Commentaires   
Commentaire de Patrice Boulanger [ 04/déc./06 11:13 ]
Avant de migrer Tellus, on va installer la nouvelle version sur Saturne qui est déjà en AS 4. Le compte "bo" a été créé sur ce serveur. L'accès firewall est en cours d'ouverture.
Commentaire de Patrice Boulanger [ 14/déc./06 10:08 ]
La nouvelle version a été installé sur Saturne et est en cours d'utilisation par le B.I.

On va programmer la mise à jour en Redhat AS4 update 4 sur Tellus dès que possible.
Commentaire de Patrice Boulanger [ 30/mars/07 16:55 ]
La migration sur Tellus est terminée.
Commentaire de Justin Ziegler [ 06/août/07 15:15 ]
On peut fermer ?
Commentaire de Agathe Remy [ 06/août/07 15:24 ]
Pas sure : Patrice voulait migrer BusinessObjects en interne de salon vers brice, je crois?!
C'est une sous-tâche de ce JIRA non effectuée...

Agathe
Commentaire de Patrice Boulanger [ 16/avr./08 13:44 ]
Migration BO sur serveur dédié prévue courant Q2 2008




[cobrand] SFR Metatache (APP-14627)

[APP-14777] [Co brand SFR] BI Création: 25/janv./07 10:26  Mise à jour: 09/nov./07 14:51  Echéance: 05/mai/08 00:00  Résolue: 20/juil./07 19:20

Etat: Fermé
Projet: Application PriceMinister
Composants: Cobrandings
Affecte la/les version(s): 12.0.0
Version(s) corrigée(s): 17.1.1

Type: Sous-tâche Priorité: Critique
Rapporteur: Ghislain Gridel Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Site: Prod
Projets PM: *** RESERVE ***
Projets PM archivés: Maintenance 12.0.0

 Commentaires   
Commentaire de Ghislain Gridel [ 25/janv./07 10:36 ]
Il faudra envoyer un rapport de type CAMIFau partenaire.

Destinataire : julien.brault@fr.sfr.com

Cependant, les délais de ce partenariat sont un peu particulier :

Déploiement du cob : 06/02

Ouverture du portail SFR : début Avril

Donc l'envoi du rapport se fera début avril.

Merci

Ghislain

Commentaire de Patrick Condevaux [ 25/janv./07 10:57 ]
Desole, je ne peux pas deplacer cette sous-taches vers le projet BI (elle est deja liée a une tache APP)

Agathe est-ce que tu veux que je cree un JIRA dans le projet BI ou ca te vas comme ca ?
Commentaire de Agathe Remy [ 25/janv./07 11:00 ]
Le rapport existant déjà, c'est bon comme ça.

Agathe
Commentaire de Thomas Séglard [ 02/avr./07 17:30 ]
Demande de rapport reportée à début mai.
Commentaire de Ghislain Gridel [ 10/avr./07 15:28 ]
lancement du partenriat décalé au 25 mai.

Ghislain
Commentaire de Agathe Remy [ 11/juin/07 18:40 ]
Bonjour,

Pourrais-je savoir où ça en est?

Merci:-)

Agathe
Commentaire de Ghislain Gridel [ 14/juin/07 17:02 ]
C'est en ligne le 25 juin (normalement).

tu peux donc programmer les rapports type "Camif" pour le dimanche 1er juillet.

les contacts sont julien.brault@fr.sfr.com et cyril.clerget@fr.sfr.com

merci.

Ghislain
Commentaire de Ghislain Gridel [ 04/juil./07 11:53 ]
Agathe,

La mise en ligne est décalée au 9 juillet.

Le rapport peut donc partir le 15 juillet.

Merci.

Ghislain
Commentaire de Agathe Remy [ 20/juil./07 19:20 ]
Le reporting hebdo (2 rapports) est programmé à partir du 22/07/2007 et le reporting mensuel (listing des nouveaux comptes) à partir du 02/08/2007.

Cordialement,
Agathe
Commentaire de Ghislain Gridel [ 20/juil./07 19:27 ]
ok. parfait merci.




[BIN-273] [Finance] : Adaptation fonctionnelle de la gestion de la TVA pour les rapports BI pour les PLF rance et Espagne Création: 22/déc./06 12:18  Mise à jour: 25/juin/07 18:53  Echéance: 29/janv./07 00:00  Résolue: 11/mai/07 11:44

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Critique
Rapporteur: Fréderic Tiberghien Attribution: Agathe Remy
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: Microsoft Word SF_BI_v2.doc     Microsoft Excel VAT_exempted_items_FR.csv     Microsoft Excel VAT_exempted_items_FR_200703.csv     Microsoft Excel VAT_items_ES.csv     Microsoft Excel VAT_items_ES_200703.csv    
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
BIN-332 [Finance] : Liste des transactions no... Sub-improvement Fermé Romain Czornomaz  
Pays:
ALL - Tous

 Description   
Les specs BI pour l'Espagne précise un petit peu plus le besoin : P 32 - 34 (doc attaché)

La modification fonctionnelle de la gestion de la TVA implique la création de 2 tableaux différents sur les plates formes France et l'Espagne.
Cette refonte consiste à adapter précisément l'application de la TVA sur les commissions à la législation européenne.
Sont donc introduits : la TVA espagnole et la notion d'exemption de la TVA.

Les tableaux de bord BO à produire sont donc :
¿ Sur la plate forme française :

TVA française
19,60% base x
TVA calculée y
TVA système z
5,50% base x
TVA calculée y
TVA système z
2,10% base x
TVA calculée y
TVA système z
Total
base somme des x = A
TVA calculée somme des y = B
TVA système somme des z = C
Exo TVA base A

Total
général base Somme des A
TVA calculée Somme des B
TVA système Somme des C

¿ Sur la plate forme espagnole :
TVA française
19,60% base x
TVA calculée y
TVA système z
5,50% base x
TVA calculée y
TVA système z
2,10% base x
TVA calculée y
TVA système z
Total
base somme des x = A
TVA calculée somme des y = B
TVA système somme des z = C
TVA espagnole
16,00% base x'
TVA calculée y'
TVA système z'
4,00% base x'
TVA calculée y'
TVA système z'
2,10% base x'
TVA calculée y'
TVA système z'
Total
base somme des x' = A'
TVA calculée somme des y' = B'
TVA système somme des z' = C'
Exo TVA base A''

Total
général base A + A' + A''
TVA calculée B+ B'
TVA système C + C'


 Commentaires   
Commentaire de Agathe Remy [ 22/déc./06 14:28 ]
Frédéric,

L'ancien rapport commission breakdown a été migré sous BusinessObjects depuis plusieurs mois.
Je pense qu'il faudrait que tu vois à quoi ressemble le rapport actuel afin de baser tes spécifications sur des informations à jour.
Peut-on se voir rapidement afin que je te présente le rapport actuel?

Merci:-)

Agathe
Commentaire de Fréderic Tiberghien [ 22/déc./06 14:36 ]
je ne suis pas la la semaine prochaine, et je pars à 16h cet aprem.
On se voit donx à la rentrée quand tu veux.

La description des nouveaux tableaux à créer a été faite avec Philippe sur la base du nouveau tableau sorti sous BO dans l'onglet TVA, normalement reprise dans le doc joint page 32, si je ne me suis pas trompé.
Et dans ce cas, ces tableaux doivent être modifiés.

Fred
Commentaire de Agathe Remy [ 20/févr./07 19:06 ]
Le nouveau rapport Commission breakdown by month a été livré en Production sur les plateformes France et Espagne.
Les anciens rapports ont été conservés et renommés en Commission breakdown by month - old pour comparaison.

Philippe, il ne te reste plus qu'à valider!!!

Merci:-)

Agathe
Commentaire de Philippe Favrot [ 27/févr./07 12:48 ]
Agathe,
merci pour la livraison de ce rapport.
J'ai deux demandes de modifications de forme :
- onglet "commission breakdown" : classer les mois dans l'ordre chronologique croissant (idem ancien rapport).
- onglet "VAT breakdown" / Spain : au niveau du VAT country Spain rajouter des colonnes (qui seront à 0) dans le cas où la requête inclus des mois antérieurs à février de manière à avoir sur la même colonne toutes les informations (France / Espagne et Total) concernant un même mois.
Par ailleurs pour pouvoir valider le fonds (c'est à dire la correcte ventilation des transactions par taux de TVA) peux tu me donner le détail des ventes (avec mention du vendeur : nom / pays et le type d'article) qui constituent les rubriques suivantes
- "exonération" pour le rapport France (à ce matin il y avait par exemple 6 758 ¿ pour le mois de février) ;
- 5,5 % / 19,6 % / 4 % / 16% du rapport Espagne .
Merci
Philippe
Commentaire de Agathe Remy [ 01/mars/07 19:29 ]
Philippe,

Pour l'extraction du détail des ventes, peux-tu me confirmer le format demandé:
item_id;seller_account_id;seller last name;seller country; product type code
?

D'autre part, lorsque tu parles de pays du vendeur, fais-tu allusion :
- au pays de la transaction (VAT_COUNTRY)
- au pays de paiement du vendeur
- au pays d'expédition du vendeur (un vendeur peut se faire payer en France et expédier de Belgique)
???

Merci:-)

Agathe
Commentaire de Agathe Remy [ 06/mars/07 21:37 ]
Voici le listing des transactions effectuées sur la plateforme Espagne.

Cordialement,
Agathe
Commentaire de Agathe Remy [ 06/mars/07 21:40 ]
Et voici le listing des transactions capturées exemptées de TVA sur la plateforme France.
Je t'ai mis le détail des pays de paiement, de compensation et d'expédition parce que je me suis dit que ce serait le meilleur moyen pour toi de vérifier.
Voici les règles de gestion qui étaient fournies dans les sépcifications :
Il faut récupérer le pays d'appartenance du vendeur. On le récupère dans l'ordre par :
o Le pays défini dans l'adresse de paiement du vendeur
o Le pays défini dans l'adresse bancaire de compensation du vendeur
o Le pays d'expédition défini au niveau compte vendeur

Pour les vendeurs particuliers membres de la CEE hors France ou Espagne, on indique le pays de la maison mère Babelstore à savoir : la France.
Pour les vendeurs particuliers hors CEE, qui sont exemptés de TVA, on indique comme pays par défaut la France.
Pour les vendeurs professionnels hors France et Espagne, qui sont exemptés de TVA, on indique le pays de la maison mère Babelstore à savoir : la France.

Cordialement,
Agathe
Commentaire de Agathe Remy [ 13/avr./07 16:52 ]
Philippe,

As-tu eu le temps de valider le nouveau rapport? Peut-on supprimer l'ancien dans BI?

Merci:-)

Agathe
Commentaire de Philippe Favrot [ 16/avr./07 18:27 ]
Agathe,
J'ai commencé mais pas fini :-(
C'est Claudie qui va gérer la fin de ce dossier ; je viens de passer 1/2 heure avec elle pour la briefer et lui donner tous les éléments en ma possession.
On te revient donc rapidement.
Merci
Philippe
Commentaire de Philippe Favrot [ 24/avr./07 11:24 ]
Bonjour Agathe,
des anomalies mises en évidence, mais qui s'expliquent probablement en partie par le fait que sur le mois de février ont coexisté à la fois l'ancien et le nouveau système de gestion de la TVA.
Pour valider ce point nous avons besoin que tu nous sortes les rapports identiques pour le mois de mars.
Merci
Philippe
Commentaire de Agathe Remy [ 26/avr./07 19:06 ]
Les fichiers des transactions exemptées de TVA France et de toutes les transactions Espagne créées en mars 2007 ont été générés et attachés au JIRA.

Cordialement,
Agathe
Commentaire de Claudie Dufresne [ 04/mai/07 18:35 ]
Agathe,

Sur les fichiers de mars, on a constaté les anomalies suivantes concernant les transactions France uniquement :

1- Particuliers exonérés de TVA alors que le pays de référence est chaque fois la France, 3 sellers account, cf ci-dessous :
57947926 12430583 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN INDIVIDUAL GAMES 19,6
58621686 12430583 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN INDIVIDUAL GAMES 19,6
58634397 12430583 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN INDIVIDUAL GAMES 19,6
59777727 13802080 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN INDIVIDUAL CONSOLE 19,6
59785427 12430583 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN INDIVIDUAL GAMES 19,6

2- Professionnels exonérés de TVA alors que le pays de référence est chaque fois la France, 1 seller account, cf ci-dessous :
58520202 1097015 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN PRO COMPONENT 19,6
58596060 1097015 FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN FRANCE, METROPOLITAN PRO STORAGE 19,6

Peux-tu nous dire s'il y a une explication,

Merci à toi
claudie


Commentaire de Agathe Remy [ 09/mai/07 10:44 ]
Bonjour Arnaud,

Peux-tu répondre à Claudie?

Je suis à ta dispo si tu as besoin de précisions.
Merci:-)

Agathe
Commentaire de Arnaud Forgues [ 09/mai/07 14:57 ]
Agathe, Claudie,

Voici les raisons de ces "anomalies" qui n'en sont pas en fait ! :
- le pays de la transaction qui est défini comme l'a décrit Agathe précédemment, est stocké lors de la mise en panier de l'article, .
- cela n'a donc pas de sens d'extraire les pays de paiement, de compensation et d'expédition en plus du pays de la transaction afin de vérifier la bonne application des règles de gestion, car ceux-ci ont pu changer entre la mise en panier de l'article (calcul du pays de transaction) et l'extraction du rapport BI.
- Afin de faire tout de même cette vérification (si vous y tenez), il faudrait archiver les pays de paiement, compensation et expédition au moment de la mise en panier de l'article, ce qui n'est pas le cas actuellement ==> DEV
- J'ai pu vérifié cette hypothèse sur 2 des 3 vendeurs ci-dessus :
            * 12430583 : marubozu était Suisse (j'ai pu le vérifier sur le site d'integ qui date de mi mars) avant de passer Francais au niveau du pays de paiement
            * 13802080 : est Francais actuellement mais a créé son compte après la mise à jour du site d'integ, du coup je ne peux pas vérifier qu'il était non francais lors de la mise en panier de l'article 59777727. De plus il n'a pas fait d'autre vente depuis. Mais on pourra vérifier lors de sa prochaine vente qu'on lui applique bien la TVA francaise
            * 1097015 : 1097015 était Luxembourgeois (vu en integ) avant de passer Francais.

Malheureusement, on n'a pas d'évenement nous permettant de tracer ces changements de pays (excepté une date de modification qui est en place depuis la V14 mais qui n'est pas suffisante pour ce ce genre de pb). Et donc si cela est nécessaire cela nécessite du DEV.

Voilou. Si vous avez besoin de plus d'explications, n'hésitez pas à venir me voir.
Je retransmet donc le JIRA à Agathe pour la suite des évenements !

Arnaud
Commentaire de Philippe Favrot [ 10/mai/07 17:36 ]
Arnaud,
merci pour ces explications c'est très clair pour nous.
Je ne pense pas qu'il faille faire du dev pour archiver les changements de pays.
En revanche, Claudie va faire un Jira à l'Equipe d'Agathe pour qu'on ait les moyens d'obtenir tous les mois la liste des transactions exonérées de TVA ; on conservera de notre côté le résultat de ces requêtes qu'on pourra produire en cas de contrôle de la part de l'administration fiscale (on aura simplement en anomalie les éventuels changements de pays entre la date de mise en panier et le début du mois suivant ; donc peu important).

Fred,
je pense que tu peux à présent fermer ce Jira.

Merci
Philippe




[cob] META-TACHE Fermeture Epik (APP-25109)

[APP-25116] Nettoyage BI après suppression cob Epik Création: 29/avr./09 19:11  Mise à jour: 01/oct./09 11:27  Résolue: 28/sept./09 12:25

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 53.0.4

Type: Sous-tâche Priorité: Mineur
Rapporteur: Fabrice Feugas Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Description   
Nettoyer le code côté BI des cobs cités dans le titre et qui ont été arrêtés.

 Commentaires   
Commentaire de Agathe Remy [ 30/avr./09 11:42 ]
Intégration des emails dans le flux Pn Data prévue pour le flux mensuel du 02/07
Commentaire de Fabrice Feugas [ 28/sept./09 12:10 ]
Cyril, ce JIRA n'a plus lieu d'être ouvert non?
Commentaire de Cyril Tanneau [ 28/sept./09 12:21 ]
Fabrice,

Les membres ont en effet été intégrés au flux mensuel PNDATA à la date prévue (début Juillet)

On peut fermer le JIRA,

Merci,

Cyril




[cob] META-TACHE Fermeture LeProgrès (APP-28357)

[APP-28364] Nettoyage BI après suppression cob LeProgrès Création: 18/févr./10 17:49  Mise à jour: 31/mai/10 10:32  Résolue: 26/mai/10 18:20

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 69.0.1.1

Type: Sous-tâche Priorité: Mineur
Rapporteur: Fabrice Feugas Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Description   
Nettoyer le code côté BI des cobs cités dans le titre et qui ont été arrêtés.

 Commentaires   
Commentaire de Fabrice Feugas [ 19/avr./10 12:23 ]
A priori c'est ok ce JIRA non ?




[EXP-1482] BI : création d'un user babel_bi sur GLOB de Jupiter Création: 09/mars/06 11:41  Mise à jour: 25/juin/07 18:56  Résolue: 29/mars/06 17:29

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Edouard Laurent
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File test_prod.sql    

 Description   
Bonjour,

Nous avons essayé de connecter notre alimentation du Datawarehouse BI sur la standby de Mercure. Or il semble que les droits que nous avons sur une standby en read-only ne sont pas suffisants pour permettre cette alimentation.
Nous avons alors adopté une solution provisoire qui consiste à alimenter le datawarehouse à partir de Titan. Or cette solution nous oblige à attendre la fin de la synchronisation pour commencer l'alimentation du Datawarehouse sur Latone, ce qui amène la fin de notre alimentation à 11h AM. L'application BI n'est donc pas à jour avant cette heure-là.
Nous aimerions donc lancer notre alimentation directement à partir de la base GLOB de Jupiter. Nous la programmerions à 2h AM afin de perturber le moins possible le site. Le chargement des données dure environ 1/2 heure. Afin de le faire de façon sécurisée, nous aimerions que vous nous créiez un user babel_bi qui n'aurait que des droits en lecture (SELECT) sur les synonymes de babel_1.

Je reste à votre disposition pour toute question.

Merci:-)

 Commentaires   
Commentaire de Sébastien Tournay [ 09/mars/06 12:41 ]
Edouard,

Je te laisse faire le point avec DIB pour mettre cela en place.
Commentaire de Edouard Laurent [ 14/mars/06 10:40 ]
Je pense que faire l'allimentation du DW depuis Jupiter est une mauvaise idee car cela va a l'encontre des objectifs de disponibilite du site que nous nous sommes fixes et ce n'est pas compatible avec les deploiements.

Je vous propose plutot d'essaye de resoudre le probleme d'allimentation depuis une standby.
Etant donne que le chargement est rapide ( ~ 1/2h ) on peut imaginer ouvrir une standby pendant une periode pour etre exactement dans la meme configuraiton que jupiter. Je vais voir avec D Blanc si ce n'est pas trop complique d'ouvir sur un creneau d'une heure ou deux la nuit.





Commentaire de Agathe Remy [ 14/mars/06 12:09 ]
Dans ce cas, il faut que tu trouves le bon paramétrage à appliquer à la standby en read-only pour que l'exécution de cette requête à partir de l'ODS sur Titan fonctionne:-)
Commentaire de Edouard Laurent [ 17/mars/06 11:58 ]
Je ne trouve pas de solution en 9i, il faudra attendre la 10g pour alimenter le DW depuis une standby.

On va donc utiliser la base OLTP. Pour cela je vais creer un utilisateur qui a uniquement les droits de "select" sur les tables de "babel_1" (ou plutôt les synonymes).

Il faut integrer dans le processus de deploiment, l'interdiction de se connecter a ce user pendant les deploiements pour eviter au maximun les problemes.

 

Commentaire de Edouard Laurent [ 22/mars/06 10:38 ]
Didier a cree le user hier, il faut tester maintenant la procedure d'alimentation de DW depuis GLOB.

Attention de bien me prevenir avant de planifier ou lancer la prodedure d'alimentation.
Il faudra surveille la charge de la base et la disponibilite du site les premieres fois et etre bien sur que ca ne va pas se derouler en meme temps qu'un deploiement ou un mini deploiement.

Merci




[EXP-4616] [BI] : Problèmes de lenteur dans l'accès à bi.priceminister.com Création: 14/nov./08 14:49  Mise à jour: 24/févr./09 16:35  Résolue: 24/févr./09 16:35

Etat: Résolu
Projet: Exploitation
Composants: Troubleshooting
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Patrice Boulanger
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour Patrice,

Régulièrement, l'accès à l'application bi.priceminister.com connaît des lenteurs pénalisantes pour l'utilisation de l'application : temps de connexion très long, affichage des pages ou téléchargement de l'applet durant plusieurs minutes, ...
Il me semble que cela ne vient pas du serveur BusinessObjects (ou de l'applicatif) puisque elasippos est très peu chargé (moins de 1 de charge, même lors de ces problèmes).
Je me demande donc si cela provient du réseau ou bien du serveur front Web par lequel nous passons.
Nous avons de plus en plus de remontées de nos utilisateurs sur ce problème que nous ne savons pas comment traiter.
S'il te plait, pourrais-tu nous aider d'où proviennent ces lenteurs et voir comment y remédier?

Merci.
Agathe

 Commentaires   
Commentaire de Patrice Boulanger [ 24/févr./09 16:35 ]
Les problèmes de lenteur réseau sont résolus suite à la suppression d'une ACL limitant la BP vers certains serveurs web.

Je clos le jira.

Merci.




[BIN-477] Changement de destinataire es rapports BI Création: 25/août/08 18:37  Mise à jour: 02/sept./08 19:02  Résolue: 28/août/08 18:58

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Henrieta Bubenkova Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Suite à mon départ au 31/08/08 je voudrais demander un changement de destinataire pour tous les rapports BI qui sont actuellement envoyés à mon adresse e-mail. Pourriez-vous les envoyer désormais à Ghislain Gridel: ghislain.gridel@priceminister.com qui me remplacera sur toute la partie Comparateurs et egalement à Jean-Michel Salem qui s'occupe de la gestion opérative des Comparateurs.

Merci d'avance!
Henrieta

 Commentaires   
Commentaire de Dalila Belkebir [ 28/août/08 18:58 ]
Bonjour Henrieta,

C'est fait pour les rapports suivants :

Fideliplus
Clubic - Appel à facture mensuel
Pangora - Appel à facture mensuel
Partner - Weekly revenue by tracking group
Appel à facture sur volume d'affaires par groupe de tracking
 Appel à facture sur CA par groupe de tracking

Dalila.
 




[BIN-131] Création d'un rapport acheteurs sous BI Création: 11/août/06 15:19  Mise à jour: 14/sept./07 17:18  Résolue: 02/oct./06 12:41

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Aucune correction envisagée  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures


 Description   
Salut Mohammed,

je souhaiterais programmer un nouveau rapport acheteurs sous BI portant sur les indications suivantes :
- Nb d'acheteurs depuis 1 mois
- Nb d'acheteurs depuis 12 mois
- Nb d'acheteurs depuis le debut

Si tu peux passer pour qu'on fasse ca ensemble.
Merci
Alexandra

 Commentaires   
Commentaire de Alexandra Viravaud [ 02/oct./06 12:36 ]
merci d'annuler cette demande.




[INF-535] [BI] : Arrivée de Valeria GUSA le 20/09/2010 Création: 02/sept./10 16:00  Mise à jour: 03/nov./10 12:41  Résolue: 03/nov./10 12:41

Etat: Résolu
Projet: Infrastructure
Composants: Arrivée/Départ
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Christophe Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word FICHE NOUVEL ARRIVANT VGU.doc    

 Description   
Bonjour,

Valeria GUSA rejoint l'équipe BI en CDI le 20 septembre 2010.
Toutes les infos sont dans la fiche nouvel arrivant ci-jointe.

Je dois encore définir son emplacement la semaine prochaine.
A ta dispo si tu as besoin d'autres infos.

Merci,

Agathe

 Commentaires   
Commentaire de Agathe Remy [ 02/sept./10 16:01 ]
Son trigramme sera VGU.
Commentaire de Stéphane Eccli [ 16/sept./10 11:03 ]
comptes créés, reste Jira




[BIN-681] [BuyBox]Etudes BI pre-projet Création: 06/juil./10 15:12  Mise à jour: 02/sept./10 15:51  Résolue: 28/juil./10 14:13

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Thomas Allier Attribution: Thomas Allier
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Les analyses souhaités en amont de la sortie du projet BuyBox sont les suivantes:

&#61680; Répartition des vendeurs par tranche de taux de claim
&#61680; Répartition des vendeurs par tranche de taux d'acceptation
&#61680; Répartition des vendeurs par tranche de note
&#61680; Répartition des premières ventes par tranche de prix

Selon disponibilité de l'équipe BI, une finesse d'analyse par type de produit aurait un intérêt pour les 3 premières études.

 Commentaires   
Commentaire de Thomas Allier [ 27/juil./10 18:14 ]
Fait : Répartition des vendeurs par tranche de taux d'acceptation
Commentaire de Thomas Allier [ 28/juil./10 10:28 ]
Fait : Répartition des vendeurs par tranche de note
Commentaire de Thomas Allier [ 28/juil./10 11:23 ]
Fait : Répartition des vendeurs par tranche de taux d'acceptation
Commentaire de Thomas Allier [ 28/juil./10 14:13 ]
Prix des premières ventes OK.

J'ai tout ce qu'il me faut




[EXP-1399] bi : je voudrais avoir acces a la plateforme bi de chez moi avec mon adresse ip fixe Création: 28/févr./06 09:37  Mise à jour: 25/juin/07 18:56  Résolue: 20/mars/06 16:22

Etat: Fermé
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Justin Ziegler Attribution: Sébastien Tournay
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
quels sont les fichiers de conf impacte ?
NB : j'ai deja rajoute mon adresse IP dans la config HTTP, mais cela ne semble pas etre sufisant.

 Commentaires   
Commentaire de Sébastien Tournay [ 20/mars/06 15:13 ]
En principe cela doit être suffisant. Je viens de vérifier la conf sur CUPIDON et PHAETON. Ton @IP est bien ajoutée au virtual-host bi. Il n'est pas question non plus de .htacess pour ce virtual-host et la VIP utilisée (.8) est la même que bo.priceminister.com donc au niveau du FireWall de JMH c'est bon.

Tu peux ressayer à nouveau pour voir si il ya du changement sur l'accès ?
Commentaire de Justin Ziegler [ 20/mars/06 15:46 ]
Oui, c bon depuis quelques temps.
En fait j'avais fait une erreur dans la saisie de l'adresse sur l'un des serveurs.
on peut fermer ce jira.




[BIN-515] [BI Souhaits] : Evolution des rapports de souhaits Création: 13/nov./08 10:45  Mise à jour: 22/déc./10 17:46  Résolue: 22/déc./10 17:46

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Thomas Beylot Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour

Ainsi que vu ensemble lors de notre dernier point bimensuel il faut apporter des évolutions aux deux rapports servis pour :
- faciliter l'utilisation que le service marketing peut faire de ces rapports pour établir une analyse et un reporting
- servir des données conformes à l'habitude prise de faire des reporting "mensuels"

premier point : faciliter l'analyse de l'historique
à l'instar des rapports SLTV on observe qu'il est compliqué de sortir les rapports sur tout l'historique. Aussi il serait bien de faire ce travail en amont et de déposer les rapports sur un dossier partagé.

deuxième point : améliorer les performances des rapports pour une utilisation fréquente

troisième point : améliorer la forme des rapports
ainsi que vu ensemble, le rapport "user distribution..." devrait permettre de sortir plusieurs mois sur le même rapport, afin de mesurer la variation de la distribution sur une période définie.
sur l'autre rapport (décliné en deux versions) ce serait bien d'avoir le mois renseigné en colonne, pour avoir un rapport qui serait du type :
Product family Day month wish owner New wish owner wish Created wish Closed wish Deleted wish Notified Captured GMS
BOOKS 2001/04/12 2001/04 4 4 8 0 0 0 0.00
GAMES 2001/04/12 2001/04 1 1 1 0 0 0 0.00
MUSIC 2001/04/12 2001/04 4 4 8 0 0 0 0.00
VIDEO 2001/04/12 2001/04 3 3 3 0 0 0 0.00


quatrième point : "mensualiser" les rapports
Actuellement, soit on sort les datas sur une période donnée mais on n'a pas le détail de la période (agglomération des données)
soit on sort les datas par jour et on retraite (pour avoir le mois par exemple) mais du coup les datas ne sont pas dédupliquées
Il faut donc que lorsque je souhaite avoir le nombre de souhaiteurs sur décembre 2007, je n'ai que le nombre de souhaiteurs uniques, par exemple. A qui j'associe le nombre de souhaits exact... etc.

Enfin, je note que sur le rapport de distribution des souhaits je ne peux pas avoir sur une période le nb de souhaits actifs mais seulement le nb de souhaits déposés sur la période (enfin, on pourrait l'avoir mais ça coute cher).

Merci

Thomas.


 Commentaires   
Commentaire de Agathe Remy [ 13/nov./08 18:59 ]
Thomas,

Pour info, nous sommes hyper chargés jusqu'à fin janvier 2009, notamment avec le BI Abonnement et le BI UK.
Heureusement, nous avons prévu un créneau en Q1 2009 pour traiter ces évolutions.

A ta dispo pour en discuter.
Agathe
Commentaire de Dalila Belkebir [ 18/sept./09 18:17 ]
Bonjour Carole,

Comme vu avec Thomas, peux-tu regarder ce JIRA et mettre à jour la demande en terme de contenus et priorisation ?

Merci d'avance.

Cdlt,
Dalila.
Commentaire de Julien Girardet [ 22/déc./10 17:46 ]
doublon avec le JIRA BIN-696. je ferme le JIRA




[cob] META-TACHE Fermeture Dauphiné Libéré et CamifOccasion (APP-25678)

[APP-25685] Nettoyage BI après suppression cob Dauphiné Libéré et CamifOccasion Création: 19/juin/09 14:31  Mise à jour: 28/janv./10 11:56  Résolue: 18/nov./09 12:11

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 61.0.0 (CTN-O)

Type: Sous-tâche Priorité: Mineur
Rapporteur: Fabrice Feugas Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Description   
Nettoyer le code côté BI des cobs cités dans le titre et qui ont été arrêtés.

 Commentaires   
Commentaire de Fabrice Feugas [ 18/nov./09 11:35 ]
Cyril, t'as une idée sur quand sera planifiée cette tâche ?
Commentaire de Fabrice Feugas [ 18/nov./09 12:11 ]
Déjà fait.




[BIN-655] [MKT] Historique rapport BI "Daily item follow up by advert tracking and product family" Création: 24/févr./10 10:46  Mise à jour: 05/mars/10 17:57  Résolue: 05/mars/10 16:32

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Audrey Angleys Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello,

Comme discuté, je souhaiterais retrouver l'historique (depuis janvier 2008) de ce rapport BI: Item / Daily item follow up by advert tracking and product family, qui me permet de suivre les ventes trackées.

Idéalement, si on pouvait également avoir ce rapport en mensuel, cela éviterait d'avoir des fichiers excel trop lourds...

Merci beaucoup,

Audrey

 Commentaires   
Commentaire de Dalila Belkebir [ 25/févr./10 15:41 ]
Audrey,

Ton extract tu la veux maintenant au format date ou mois ?
Tu la veux sur quels groupes de tracking annonces?

Cdlt,
Dalila.
Commentaire de Audrey Angleys [ 25/févr./10 16:31 ]
Dalila,

Oui si je pouvais avoir l'extract au format mois, ce serait parfait.

Voici les groupes de tracking que je suis plus particulièrement:
- Automatisation
- PL-Maison
- PL-Mode
- PL-high-tech
- PL-culturelle
- Post-clic
- Priceletterx
- Priceletter-VF
- Priceletter-vente

Merci beaucoup!

Audrey
Commentaire de Dalila Belkebir [ 05/mars/10 16:32 ]
Audrey,

Je suis en cours de génération de l'historique comme demandé.
Tu trouveras les fichiers sur le serveur All_PM et dans le répertoire :
BI\02 - Historiques de données\2010-03 Monthly item follow up by advert tracking and product family

Les données ne sont pas triées et seront réparties sur 4 fichiers (un par semestre).
Merci de me confirmer que cela te convient.

Cdlt,
Dalila.
Commentaire de Audrey Angleys [ 05/mars/10 16:45 ]
Merci beaucoup Dalila, c'est exactement ça!

Merci

Audrey
Commentaire de Dalila Belkebir [ 05/mars/10 17:57 ]
OK audrey.

Je ferme donc le JIRA.

Cdlt,
Dalila.




[BIN-397] [Label vendeur] : url label vendeur dans BI Création: 20/déc./07 11:22  Mise à jour: 21/déc./07 18:12  Résolue: 20/déc./07 12:36

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Ghislain Gridel Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut Agathe,

peux-tu rajouter l'url des sites qui ont intégrés le labels vendeurs dans BI, stp ?

Merci !

Ghislain

 Commentaires   
Commentaire de Agathe Remy [ 20/déc./07 12:36 ]
Ghislain,

Le label vendeur a été ajouté dans l'univers FRANCE - USER ACCOUNT. Tu le trouveras dans la classe User Account sous le nom Seller website URL.

Agathe
Commentaire de Ghislain Gridel [ 20/déc./07 14:19 ]
merci




[BIN-296] données manquante sur résultats newsletter à 30j dans BI Création: 26/févr./07 14:11  Mise à jour: 14/sept./07 18:02  Résolue: 26/févr./07 15:35

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Charlotte Fachan Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut Agathe,

dans BI je n'arrive pas à retrouevr les données relatives à la newsletter Pl-maison34-soldesmarques
le code de tracking associé est 1708041
et le groupe de tracking sous lequel tout cela a été enregistré : Post-Clic

Sur BI, dans purchase by purchase tracking, pas d'infos (VA, com, paniers....)?

Cette news aurait-elle disparue du reporting? Comment récupérer ces chiffres?

Merci

Charlotte

 Commentaires   
Commentaire de Agathe Remy [ 26/févr./07 14:23 ]
Charlotte,

Sur quelle période as-tu rafraîchi le rapport?

Merci:-)

Agathe
Commentaire de Agathe Remy [ 26/févr./07 14:34 ]
En fait, le nom à la création de ce tracking était : post-clic-DVD.
Comme il n'y a pas de suivi des modifications de cette table, le nom mis à jour sur le site n'est pas mis à jour dans la base de reporting.
Tes données sont donc celles du tracking post-clic-DVD.

Cordialement,
Agathe
Commentaire de Charlotte Fachan [ 26/févr./07 14:37 ]
euh...

du 23/01/07 au 23/02/07!

merci

Charlotte
Commentaire de Charlotte Fachan [ 26/févr./07 14:43 ]
oui le nom a été modifié en effet...

Cela signifie-t-il que les données de cette news sont mélangées aux résultats post-clic DVD????
Commentaire de Agathe Remy [ 26/févr./07 14:53 ]
Bah oui... Sinon fallait créé un nouveau tracking?!

Agathe
Commentaire de Agathe Remy [ 26/févr./07 15:35 ]
C'est bon : j'ai mis à jour les libellés de tracking dans la base de reporting.
J'ai vérifié qu'il n'y avait pas de panier avant le 23/01/2007 associé au tracking PL M&L.

Tout semble donc OK.
D'autre part, je vais voir avec l'équipe Dév comment tracer vos modifications de libellé de tracking...

Agathe




[BIN-642] Il y a plus de paniers authorisés qui remontent chez le partenaire que sur BI Création: 23/déc./09 15:48  Mise à jour: 28/déc./09 17:50  Résolue: 28/déc./09 17:24

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Bloquant
Rapporteur: Jonathan Gorges Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Match panier effiliation 2.xls    
Pays:
FRA - France

 Description   
Bonjour,

Nous rencontrons un problème entre les données BI et les données plateforme chez Effiliation.

En effet, nous remontons plus de paniers autorisés via le tag Effiliation (trackés effilaition) sur l'extranet de la plateforme que le nombre de paniers autorisés présents dans l'export bi.

Exemple pour la journée du 10/12/2009 nous obtenons:
Sur l'extranet plateforme: 1950 paniers authorisés.
Sur l'export : dans l'univers Purchase > Weekly purchase overview (30 days tracking) : groupe Affiliationx: 1383 paniers authorisés.

Soit un manque de 557 paniers sur BI.

L'appel du tag est conditionné à la présence d'un tracking du groupe Affiliationx; nous ne voyons donc pas comment cela est possible de se retrouver dans cette situation.

Nous vous mettons en pièce jointe les différentes données dans le fichier: Match panier Effilaiton.xls
Voici le descriptif des onglets:
            Extract plateforme: donner plateforme
            Extract BI:
            Recherv : la recherche sur les planiers plateformes de l'équivalent panier sur bi
            Recherv coller en valeur: l'onglet précédent copier en valeur= paniers qui ne sont pas dans BI: liste des paniers présents sur l'extranet plateforme mais qui ne le sont pas dans BI.

Merci pour votre retour sur ce sujet alarmant

 




 Commentaires   
Commentaire de Dalila Belkebir [ 23/déc./09 15:54 ]
hello Jonathan,

Je ne vois pas de PJ sur le JIRA.

As-tu déjà regardé ce point avec Mathilde car nous avons déjà dû regarder un écart sur le groupe Affiliationx ou affliquelquechose (attention au paramétrage des groupes/tracking name) ?

Les paniers remontés via le tag sont bien autorisés ? non abandonnés (paniers créés mais non validés par le user)?

Le sujet n'est pas alarmant tant que le pb n'a pas été clairement identifié. Une fois le pb identifié nous pourrons le qualifier. Pour le moment je ne vois que l'urgence de vérifier cet écart.

A ta dispo,
Dalila.
Commentaire de Dalila Belkebir [ 28/déc./09 17:24 ]
Bonjour Jonathan,

Comme vu ensemble le pb ne se situe pas au niveau des données, qui sont celles enregistrées dans le système.

Pourrais-tu STP préciser d'où vient le pb au final (taggage des paniers ?)?
As-tu pu voir la manip à faire côté paramétrage afin de corriger le pb?

merci de ton retour pour clôture du JIRA.

cdlt,
Dalila.
Commentaire de Jonathan Gorges [ 28/déc./09 17:34 ]
Hello,

Le problème semble avoir été résolu. Je ne sais pas encore comment...

Vous pouvez fermer le Jira.

Merci pour votre aide.

Bonne journée.

Jonathan.




[INF-91] BI : arrivée de Dalila le 1er juillet 2008 Création: 18/juin/08 15:44  Mise à jour: 07/juil./08 15:24  Résolue: 07/juil./08 15:24

Etat: Fermé
Projet: Infrastructure
Composants: Arrivée/Départ
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Christophe Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word FICHE NOUVEL ARRIVANT DBE.doc    

 Description   
Bonjour,

Notre chef de projet BI arrive le 1er juillet 2008.
Dans un premier temps, elle prendra le poste de Florian AMBROSI qui termine son stage le 30 juin, puis elle s'installera à la place de Romain à partir du 24 juillet.
Toutes les autres infos sont dans la fiche nouvel arrivant ci-jointe.

A ta dispo si tu as besoin d'autres infos.

Merci.

Agathe


 Commentaires   
Commentaire de Stéphane Eccli [ 01/juil./08 14:20 ]
compte reseau et mail ok
reste Jira
Commentaire de Christophe Garcia [ 07/juil./08 15:24 ]
JIRA OK




[APP-19182] BI: Création de la CHANGE_DATE sur usr_message Création: 16/janv./08 16:40  Mise à jour: 04/févr./08 15:30  Résolue: 21/janv./08 15:49

Etat: Fermé
Projet: Application PriceMinister
Composants: Base de données
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 19.0.0

Type: Nouvelle fonctionnalité Priorité: Critique
Rapporteur: Romain Czornomaz Attribution: Renaud Dierickx
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
ALL - Tous
Site: Prod
Projets PM archivés: Maintenance 19.x.x

 Description   
Bonjour,

Dans le cadre de la mise en place du BI Backoffice pour Q1 2008, nous avons à importer les différents éléments liés aux messages utilisateurs.
Le backoffice est ammené à modifier le contenu des enregistrements lors du traitement des messages.
Or, actuellement la table ne possède pas de CHANGE_DATE indispensable de notre coté pour effectuer des chargements incrémentaux avec les enregistrements modifiés.

Serait-il possible de planifier cette évolution de l'application pour les prochaines versions du site?

Merci d'avance,

Romain




 Commentaires   
Commentaire de Nicolas Chauveau [ 17/janv./08 15:58 ]
Verifier le besoin : creation_date / change_date
Commentaire de Renaud Dierickx [ 21/janv./08 15:46 ]
C'est fait et testé sur le tronc.
J'affiche la change_date en infobulle lorsqu'on met le curseur sur la creation_date :
- sur l'écran de recherche d'un message
- sur l'écran de recherche de configuration du message (voir screenshoot)
Commentaire de Espérance Galouo-Lece [ 04/févr./08 15:30 ]
Done.




[EXP-3482] BI : problème de temps d'alimentation du Datawarehouse sur Latone Création: 12/avr./07 14:16  Mise à jour: 14/avr./08 17:56  Résolue: 14/avr./08 17:56

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Nous avons modifié la clause de sélection des données de la veille sur les tables chargées en incrémentales le 11/04/2007.
Pour le chargement des données de la table ITEM de jupiter vers latone, les temps de traitements sont passés de 700 secondes en moyenne à plus de 8000 secondes:-(
Le plan d'exécution de l'ancienne requête fait un FULL scan de la table alors que la nouvelle passe par l'index ITEM_IX qui n'a pas été analysé depuis le 05/10/2006...
C'est la première fois que je vois un full scan plus rapide que le passage par un index?!

En attendant l'intervention d'un DBA expérimenté sur la base de production du site, nous avons remis l'ancienne condition...

Agathe

 Commentaires   
Commentaire de Patrick Pereira [ 25/avr./07 14:35 ]
Peux-tu me donner la condition que tu as utilisée pour le 11/04/2007 ?
Commentaire de Agathe Remy [ 25/avr./07 14:46 ]
cible :
(ITEM.CREATION_DATE >= TRUNC(sysdate-2)
OR ITEM.CHANGE_DATE >= TRUNC(sysdate-2)
)
AND ITEM.CREATION_DATE < TRUNC(sysdate)

actuellement :
(ITEM.CREATION_DATE >= TRUNC(sysdate-2)
AND ITEM.CREATION_DATE < TRUNC(sysdate)
)
OR ITEM.CHANGE_DATE >= TRUNC(sysdate-2)
Commentaire de Patrick Pereira [ 15/janv./08 12:17 ]
La requête actuelle à la forme suivante :
SELECT /*+ OPAQUE_TRANSFORM */
ITEM_ID,BUYER_ACCOUNT_ID,SELLER_ACCOUNT_ID,CREATION_DATE,CHANGE_DATE,ADVERT_ID,PURCHASE_ID,ITEM_COST_PRICE,ITEM_COMMISSION_TAX_RATE,SHIP_COST_PRICE,SHIP_COMMISSION_TAX,SHIP_COMMISSION_TAX_RATE,SHIPPING_TYPE_ID,RETURN_SHIPPING_PRICE,CURRENCY_ID,BUYER_COMMENT
,SELLER_SCORE,ITM_STATUS_CODE,CLOSING_DATE,COMPENSATION_ID,COMPENSATION_PROCESSING_DATE,IS_ABANDONNED,BUYER_BONUS,SELLER_BONUS,CLAIM_COMPENSATION_ID,ITM_CLAIM_TYPE_CODE,CLAIM_COMMENT,LAST_CLAIM_DATE,CLM_STATUS_CODE,HISTORY,BUYER_REMIND_CODE,SELLER_REMIND_CODE,BUYER_REMIND_DATE,
SELLER_REMIND_DATE,ORIGIN_SCREEN,ORIGIN_BLOCK,PRODUCT_ID,SELLER_COUNTRY_ID,SELLER_LOGIN,ADV_QUALITY_CODE,ADV_SELLER_COMMENT,ADV_SERIAL_NUMBER,PRD_TYPE_CODE,PRD_MEDIUM_CODE,PRD_LIST_PRICE,PRD_CURRENCY_ID,COMMIT_DATE,CLAIM_CLOSING_DATE,
FEEDBACK_DATE,BUYER_LOGIN,ADV_SELLER_REFERENCE1,ADV_IS_ORIGINAL,ADV_TYPE_CODE,ADV_SELLER_PRIVATE_COMMENT,PRD_LINE_KEY,PRD_MODEL_KEY,SELLER_JUSTIFICATION,ITEM_FIXED_COMMISSION_NET,ITEM_FIXED_COMMISSION_TAX,ITEM_VARIA_COMMISSION_NET,ITEM_VARIA_COMMISSION_TAX,SHIP_COMMISSION_NET,COMMISSION_ID
,ITM_TYPE_CODE,ITM_CANCEL_CODE,ADV_SALE_PRICE,ADV_CURRENCY_ID,BUYER_NEGOTIATION_COMMENT,SHIPMENT_NUMBER_1,SHIPMENT_NUMBER_2,COMPLEMENT_PRODUCT_ID,SHIPPING_SIZE_ID,ADV_ALLOW_SHIPPING,ADV_ALLOW_PICKUP,ADV_PICKUP_PHONE_NUMBER,ADV_PICKUP_ZIP,ADV_PICKUP_COUNTRY_ID,IS_SELLER_VAT_EXEMPTED,
VAT_COUNTRY_ID,VAT_DISCLAIMER,SELLER_NEGO_PRICE,IS_CBV_APPLICABLE
FROM ITEM
WHERE "CHANGE_DATE">=TRUNC(sysdate-2)
OR "CREATION_DATE">=TRUNC(sysdate-2)
AND "CREATION_DATE"<TRUNC(sysdate);

Son coût et plan sont les suivants :

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 167K| 173M| 813K (1)| 02:42:45 |
|* 1 | TABLE ACCESS FULL| ITEM | 167K| 173M| 813K (1)| 02:42:45 |
--------------------------------------------------------------------------

Statistics
----------------------------------------------------------
         15 recursive calls
          0 db block gets
    2989175 consistent gets
    2562277 physical reads
          0 redo size
   66707284 bytes sent via SQL*Net to client
     163846 bytes received via SQL*Net from client
      14852 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
     222756 rows processed

Je te propose de créer les deux indexes suivants :
- ITM_IX_CREATION_DATE ( trunc(creation_date))
- ITM_IX_CHANGE_DATE ( trunc(change_date), trunc(creation_date))

La requête devient alors (j'en profite pour ajouter des '(' pour être sûr du comportement) :

SELECT "ITEM_ID","BUYER_ACCOUNT_ID","SELLER_ACCOUNT_ID","CREATION_DATE","CHANGE_DATE","ADVERT_ID","PURCHASE_ID","ITEM_COST_PRICE","ITEM_COMMISSION_TAX_RATE","SHIP_COST_PRICE","SHIP_COMMISSION_TAX","SHIP_COMMISSION_TAX_RATE","SHIPPING_TYPE_ID","RETURN_SHIPPING_PRICE","CURRENCY_ID","BUYER_COMMENT"
,"SELLER_SCORE","ITM_STATUS_CODE","CLOSING_DATE","COMPENSATION_ID","COMPENSATION_PROCESSING_DATE","IS_ABANDONNED","BUYER_BONUS","SELLER_BONUS","CLAIM_COMPENSATION_ID","ITM_CLAIM_TYPE_CODE","CLAIM_COMMENT","LAST_CLAIM_DATE","CLM_STATUS_CODE","HISTORY","BUYER_REMIND_CODE","SELLER_REMIND_CODE","BUYER_REMIND_DATE",
"SELLER_REMIND_DATE","ORIGIN_SCREEN","ORIGIN_BLOCK","PRODUCT_ID","SELLER_COUNTRY_ID","SELLER_LOGIN","ADV_QUALITY_CODE","ADV_SELLER_COMMENT","ADV_SERIAL_NUMBER","PRD_TYPE_CODE","PRD_MEDIUM_CODE","PRD_LIST_PRICE","PRD_CURRENCY_ID","COMMIT_DATE","CLAIM_CLOSING_DATE",
"FEEDBACK_DATE","BUYER_LOGIN","ADV_SELLER_REFERENCE1","ADV_IS_ORIGINAL","ADV_TYPE_CODE","ADV_SELLER_PRIVATE_COMMENT","PRD_LINE_KEY","PRD_MODEL_KEY","SELLER_JUSTIFICATION","ITEM_FIXED_COMMISSION_NET","ITEM_FIXED_COMMISSION_TAX","ITEM_VARIA_COMMISSION_NET","ITEM_VARIA_COMMISSION_TAX","SHIP_COMMISSION_NET","COMMISSION_ID"
,"ITM_TYPE_CODE","ITM_CANCEL_CODE","ADV_SALE_PRICE","ADV_CURRENCY_ID","BUYER_NEGOTIATION_COMMENT","SHIPMENT_NUMBER_1","SHIPMENT_NUMBER_2","COMPLEMENT_PRODUCT_ID","SHIPPING_SIZE_ID","ADV_ALLOW_SHIPPING","ADV_ALLOW_PICKUP","ADV_PICKUP_PHONE_NUMBER","ADV_PICKUP_ZIP","ADV_PICKUP_COUNTRY_ID","IS_SELLER_VAT_EXEMPTED",
"VAT_COUNTRY_ID","VAT_DISCLAIMER","SELLER_NEGO_PRICE","IS_CBV_APPLICABLE"
FROM "BABEL_BI"."ITEM" "ITEM"
WHERE ( trunc(CHANGE_DATE)>=TRUNC(sysdate-2) OR (trunc(CREATION_DATE)>=TRUNC(sysdate-2))
AND trunc(CREATION_DATE)<TRUNC(sysdate);

avec :

--------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 438K| 461M| | 20430 (2)| 00:04:06 |
|* 1 | TABLE ACCESS BY INDEX ROWID | ITEM | 438K| 461M| | 20430 (2)| 00:04:06 |
| 2 | BITMAP CONVERSION TO ROWIDS | | | | | | |
| 3 | BITMAP OR | | | | | | |
| 4 | BITMAP CONVERSION FROM ROWIDS| | | | | | |
| 5 | SORT ORDER BY | | | | 7000K| | |
|* 6 | INDEX RANGE SCAN | ITM_IX_BI_3 | 18M| | | 78 (2)| 00:00:01 |
| 7 | BITMAP CONVERSION FROM ROWIDS| | | | | | |
| 8 | SORT ORDER BY | | | | 6872K| | |
|* 9 | INDEX RANGE SCAN | ITM_IX_BI_4 | 18M| | | 59 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
     101925 consistent gets
          0 physical reads
          0 redo size
   66708511 bytes sent via SQL*Net to client
     163890 bytes received via SQL*Net from client
      14852 SQL*Net roundtrips to/from client
          2 sorts (memory)
          0 sorts (disk)
     222756 rows processed


On pourrait même envisager :

WHERE ( trunc(CHANGE_DATE)>=TRUNC(sysdate-2) AND trunc(CREATION_DATE)<TRUNC(sysdate))
OR trunc(CREATION_DATE) in (TRUNC(sysdate-2), TRUNC(sysdate-1) )

Qu'en penses-tu ?
Commentaire de Patrick Pereira [ 14/avr./08 17:56 ]
Pb sur item réglé par la création des indexes :
ITM_IX_BI_1(trunc(creation_date));
ITM_IX_BI_2(trunc(change_date),trunc(creation_date));




[BIN-583] [CBV] : Migration d'un rapport perso sour BI Création: 25/mai/09 09:07  Mise à jour: 11/juin/09 09:16  Résolue: 28/mai/09 10:27

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Thomas Beylot Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello,
Dans le cadre de la reprise par Julien du chantier CBV (et donc de son suivi mensuel) il faudrait que nous ayons accès à un rapport développé avec Pkr il y a un an de cela. Or ce rapport n'est accessible que dans le dossier perso de Pkr, qui lui même ne nous est pas accessible.

Pouvons nous migrer les dit rapports sous le perso de Julien ?

Les noms des rapports, dans CBV, dans le dossier pkr:
- cbv agglo 0-4.99, 5-14.99 et 15+.


merci

thomas


 Commentaires   
Commentaire de Dalila Belkebir [ 27/mai/09 09:56 ]
Bonjour,

En raison d'une opération de maintenance, la prod BI n'est pas disponible aujourd'hui.
Dès son rétablissement je me charge de la demande.

Cdlt,
Dalila.
Commentaire de Dalila Belkebir [ 28/mai/09 10:27 ]
Thomas,

Je viens de vérifier et il se trouve que le répertoire de PKR existe toujours dans les favoris du User UR Marketing.
Donc tu peux en faire une copie ou les exploiter directement : tu y as accès :-)

=> aucune action de notre part n'est nécessaire.
Cdlt,
Dalila.
Commentaire de Agathe Remy [ 10/juin/09 17:56 ]
Bonsoir Thomas,

S'il te plait, peux-tu confirmer que vous avez accès aux rapports demandés?

Merci.

Agathe

Commentaire de Thomas Beylot [ 11/juin/09 09:09 ]
Hello

je confirme !

merci beaucoup


thomas




[EXP-4647] [BI UK] Impact TX-D bis (fonction toeuro et toeuro2) sur le reporting BI sur TERRA Création: 17/déc./08 14:56  Mise à jour: 13/janv./09 14:53  Résolue: 13/janv./09 12:44

Etat: Résolu
Projet: Exploitation
Composants: Maintenance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Bloquant
Rapporteur: Dalila Belkebir Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Suite au projet BI UK, les fonctions toEuro et toEuro2 vont être migrées en toDfltCurrcyFullPrec et toDfltCurrcy
Il faut donc vérifier que cela n'impacte pas le reporting BI sur TERRA.

Cette modification interviendra le 12/01/2009 lors de la livraison des impacts UK sur les plateformes FR & ES (TXD bis).
Merci de vous assurer que les impacts TXD bis soient bien pris en compte sur le reporting le 13/01/09

toEuro et toEuro2 deviendront :

    FUNCTION toDfltCurrcyFullPrec(amount NUMBER, currencyId NUMBER) RETURN NUMBER deterministic IS
    BEGIN
      IF (currencyId = CURRENCY_FRF) THEN RETURN amount / EURO_RATE;
      ELSE RETURN amount;
      END IF;
    END;

    FUNCTION toDfltCurrcy(amount NUMBER, currencyId NUMBER) RETURN NUMBER deterministic IS
    BEGIN
      RETURN ROUND(toDfltCurrcyFullPrec(amount, currencyId), 2);
    END;

Merci.
Dalila.


 Commentaires   
Commentaire de Patrick Pereira [ 13/janv./09 12:44 ]
C'est bon.
Commentaire de Dalila Belkebir [ 13/janv./09 14:53 ]
Bonjour Patrick,

Peux-tu détailler les actions menées pour vérifier la présence ou non d'impacts du changement des fonctions de conversion des devises ?
Les fonction to-euro et to_euro2 ne sont-elles pas appelées à disparaitre d'ici peu ?

Merci de ton retour,
dalila.




[BIN-426] [Spain] : Le champ "state-id" n'est pas disponible dans BI Création: 04/avr./08 18:32  Mise à jour: 14/mai/08 15:33  Résolue: 23/avr./08 17:31

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Charles Decaux Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
ESP - Espagne

 Description   
Hello

J'ai besoin de connaître la région de certains de mes acheteurs en utilisant BI. Or dans l'ensemble "shipping address" je n'ai pas à ma disposition la région.

Serait-il possible de l'ajouter ?

Merci



 Commentaires   
Commentaire de Agathe Remy [ 23/avr./08 17:31 ]
Charles,

Peux-tu valider l'ajout des objets suivants :
SPAIN - ITEM :
Buyer account/Shipping address/Shipping address state Id
Buyer account/Shipping address/Shipping address state name
Seller account/Payment address/Payment address state Id
Seller account/Payment address/Payment address state name
Seller account/Meeting address/Meeting address state Id
Seller account/Meeting address/Meeting address state name

SPAIN - PURCHASE :
User account/Shipping address/Shipping address state Id
User account/Shipping address/Shipping address state name

SPAIN - ADVERT :
User account/Payement address/Payment address state Id
User account/Payement address/Payment address state name
User account/Meeting address/Meeting address state Id
User account/Meeting address/Meeting address state name

SPAIN - USER_ACCOUNT
Shipping address/Shipping address state Id
Shipping address/Shipping address state name
Payment address/Payment address state Id
Payment address/Payment address state name
Meeting address/Meeting address state Id
Meeting address/Meeting address state name

Merci.

Agathe
Commentaire de Charles Decaux [ 25/avr./08 10:37 ]
J'ai fait un test dans Purchase.

User account --> Shipping address --> pas de state id

je ne le trouve pas, voir screen shot

merci
Commentaire de Samir Beghdadi [ 25/avr./08 15:52 ]
Charles,

Oui c'est normal l'univers PURCHASE n'été pas encore en production.

Maintenant tu peux tester les trois univers (ITEM, PURCHASE et USER ACCOUNT).

Merci

Samir
Commentaire de Agathe Remy [ 14/mai/08 15:23 ]
Bonjour Charles,

Petite relance pour valider cet ajout?!

Merci:-)
Agathe
Commentaire de Charles Decaux [ 14/mai/08 15:32 ]
je viens de tester, c'est impeccable, merci !!




[BIN-263] ajout des champs grant_login et user compensation right code sur BI Création: 10/janv./07 10:47  Mise à jour: 14/sept./07 17:34  Résolue: 10/janv./07 13:24

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut Agathe,

il faudrait ajouter les champs grant_login et user compensation right code sur BI pour la relance auprès des personnes non abonnées à l'automatisation.
Envoi du mail via MM le 29 janvier

Merci
Alex

 Commentaires   
Commentaire de Agathe Remy [ 10/janv./07 10:50 ]
Je ne pense pas que ce soit pour le mail de relance auprès des personnes non abonnées à l'automatisation, mais plutôt le mail aux détenteurs de PMV positifs?!

Agathe
Commentaire de Agathe Remy [ 10/janv./07 10:53 ]
Au fait pour l'envoi, es-tu sure que ce n'est pas le 18/01?

Merci:-)
Commentaire de Alexandra Viravaud [ 10/janv./07 10:59 ]
oui tu as raison. j'ai fait un mix entre les 2 mails :(
Commentaire de Alexandra Viravaud [ 10/janv./07 11:22 ]
Juste pour info, j'ai ajouté la condition de validation auto (buyer reliability) est -1 ou -2 sur le rapport.
Commentaire de Agathe Remy [ 10/janv./07 13:24 ]
C'est fait : tu trouveras les objets User grant login et User compensation rigth code dans la classe User Account de l'univers France - User Account.

Pour info :
compte non bloqué : User grant login = 1
compensation non bloquée : User compensation rigth code != 20
Commentaire de Alexandra Viravaud [ 10/janv./07 17:55 ]
Agathe, je ne vois pas les dits champs sur l'univers users. Tu peux m'éclairer ?
Commentaire de Agathe Remy [ 10/janv./07 18:13 ]
C'est corrigé.

Tu devrais pouvoir les trouver à présent.

Agathe
Commentaire de Alexandra Viravaud [ 10/janv./07 18:28 ]
ca marche. merci.




[BIN-303] [Wish] : Demande de mise à disposition des données de suivi des souhaits dans BI Création: 08/mars/07 15:27  Mise à jour: 01/oct./08 10:34  Echéance: 30/sept./08 00:00  Résolue: 01/oct./08 10:34

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Thomas Beylot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Ce serait bien d'ajouter les éléments nous permettant de suivre la fonction "souhait" à BI. En fait la demande vient du fait qu'un des objo de la nouvelle FP est de booster le souhait. Donc il faut qu'on puisse le suivre :-)


merci !!

thomas

 Commentaires   
Commentaire de Agathe Remy [ 02/janv./08 11:32 ]
Thomas,

Cette demande a été planifiée pour Q3 2008.

Agathe




[BIN-142] ajout de tracking id dans les rapports BI "incitation achat" et "incitation vente" Création: 24/août/06 19:06  Mise à jour: 14/sept./07 17:19  Résolue: 02/oct./06 12:43

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures


 Description   
Mohamed,

comme prévu voici tous les codes de tracking qui doivent être présents dans nos nouveaux rapports BI incentive achat et incentive vente.

Incentive achat :
727140
727141
727142
727143
1041740
1041741
1366040

Incentive vente :
727144
727145
1396045
1402140
1396048
1464040

Peux-tu me prévenir quand c'est prêt?
Merci beaucoup.

Alexandra


 Commentaires   
Commentaire de Mohamed Ezzouak [ 25/août/06 18:28 ]
Les conditions sur les tracking ont été modifiées pour inclure les nouveaux tracking automatisation.
Les univers Purchase et Advert ont été modifiés en conséquence.

Le rapport personnal d'Alexandra a été modifié également pour prendre en considération ces tracking.

NB : Il manquait dans la liste des tracking pour les mails incitation à l'achat le numéro : 1111741
Il a été également ajouté.
Commentaire de Alexandra Viravaud [ 02/oct./06 12:38 ]
demande faite. fermer le jira




[BIN-514] [Finance] : Données manquantes dans le rapport BI "Wallet by user" Création: 13/nov./08 09:51  Mise à jour: 26/nov./08 11:38  Résolue: 13/nov./08 18:42

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Bloquant
Rapporteur: Samira Remila Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Dalila, Agathe,

Nous avons sortis le rapport BI "Wallet by user" mais nous constatons qu'il n'est pas complet car il manque le détail des PMV non actifs. Nous aurions besoins de ces données pour pouvoir avancer dans l'analyse du seller crédit.

Montant du Wallet by user ( BI ) au 1er novembre 2008 est de : 5 614 269,61¿
Montant du Wallet Report ( TITAN ) au 1er novembre 2008 est de : 7 281 225,86 ¿
Soit un écart de 1 666 956,25 ¿

Si vous avez des questions n'hésitez surtout pas.
Pourrais vous nous tenir au courant du délai qu'ils vous faudraient pour rajouter les PMV manquants ?


Merci par avance.

Samira




 Commentaires   
Commentaire de Agathe Remy [ 13/nov./08 11:36 ]
Bonjour Samira,

Pour obtenir les PMV manquants, il te suffit de rafraichir la liste de valeur dans l'invite et de sélectionner les nouveaux statuts du PMV.

Cordialement,
Agathe




[META-TACHE] Modification des tracking sites-under + tracking e-mails questions (APP-26706)

[APP-26842] Modification du rapport BI : France-> Affiliation-> Partner - Affiliation purchase checking Création: 12/oct./09 18:27  Mise à jour: 06/nov./09 16:51  Echéance: 02/nov./09 00:00  Résolue: 03/nov./09 11:25

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation
Affecte la/les version(s): 55.0.2 .1
Version(s) corrigée(s): 56.0.2

Type: Sous-tâche Priorité: Majeur
Rapporteur: Mathilde Caby Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM archivés: Tracking affiliation

 Description   
Bonjour,


Nous avons besoin de modifier le rapport BI: France-> Affiliation-> Partner - Affiliation purchase checking

En effet nous rémunérons actuellement les affiliés sur le volume d'affaire. Hors cette rémunération changera le 2 novembre prochain.
Nous rémunérerons à partir de cette date les affiliés au pourcentage de la commission hors taxe et hors frais de port.
Nous aurons donc désormais cette commission qui remontera chez les plateformes.

Actuellement le frapport BI : France-> Affiliation-> Partner - Affiliation purchase checking nous remonte le montant du volume d'affaire par panier avec la reference panier et la date de ce panier.
Nous aimerions qu'a partir du 2/10/2009 ce rapport nous remonte le montant de la commission hors taxe, hors frais de port par panier avec la référence panier et la date de celui-ci.

Il faut donc juste remplacer le montant du volume d'affaire par panier par la commission hors frais de port, hors taxe du panier.


Pour information: ce rapport nous est envoyé automatiquement tous les lundis matin pour les 2 plateformes suivantes: Zanox et Affilinet(=cibleclickx)
Et nous le générons manuellement tous les lundis pour les 2 plateformes : Effiliation et CJ.


Nous générons manuellement le rapport pour la validation des ventes du mois précédent pour les 4 plateformes en début de mois (au 10 du mois suivants maximum).
C'est pourquoi, nous aurons encore besoin de l'ancienne version du rapport jusqu'au 10/11/2009.


Je suis à votre disposition pour toutes questions
Merci
Mathilde


 Commentaires   
Commentaire de Fabrice Feugas [ 14/oct./09 15:34 ]
Présentation du projet dans cette page : http://pricewiki.lan/Wiki.jsp?page=Tracking%20afiliation%20%28Sites%20Under%20%2B%20emails%20question%29
Commentaire de Cyril Tanneau [ 20/oct./09 15:00 ]
Salut Mathilde,

tu précises dans le jira que vous aimeriez que le rapport remonte "la commission hors taxe, hors frais de port par panier". S'agit'il de la commission autorisée ou capturée?

Merci,

Cyril
Commentaire de Mathilde Caby [ 20/oct./09 16:42 ]
Hello Cyril,

Nous voulons la commission hors taxe et hors frais de port capturée stp
Commentaire de Cyril Tanneau [ 20/oct./09 16:51 ]
OK, merci Mathilde
Commentaire de Dalila Belkebir [ 02/nov./09 15:56 ]
Mathilde,

Suite à notre point de ce matin, je te propose de rester sur le capturé avec les indicateurs déjà en place (OK, ATTENDRE etc ...).

Par contre, je te propose de changer le nom des rapports à l'instar de ce qui existe sur PURCHASE/PARTNERS selon :

Partner - Affiliation purchase checking
devient
Affiliation sur volume d'affaires par groupe de tracking du panier

le nouveau rapport s'appellera
Affiliation sur commission nette hors FP par groupe de tracking du panier

De cette manière nous pourrons garder les 2 types de rapport et les exploiter si besoin(d'historique ou bien de nouveaux partanires sur ce modèle de volume d'affaires).

Souhaites-tu garder le nom des rapports en anglais ?
Commentaire de Mathilde Caby [ 02/nov./09 15:59 ]
Dalila,

C'est parfait comme proposé en français ci-dessus.
Merci
Mathilde
Commentaire de Dalila Belkebir [ 02/nov./09 19:25 ]
Mathilde,

j'ai mis en production
- le nouveau rapport : Affiliation sur commission nette hors FP par groupe de tracking du panier
- le renomage du rapport existant Partner - Affiliation purchase checking en Affiliation sur volume d'affaires par groupe de tracking du panier

Tu les trouveras dans publics folders/ France Affiliation.

Je l'ai également mis en place le nouveau rapport pour UK et ES.

J'ai exécuté le rapport en France pour Zanox et Cibleclickx que tu trouveras dans les instances exécutées.
Merci de tes retours pour validation du JIRA.

Cdlt,
Dalila.



Cordialement,
Dalila.
Commentaire de Christophe Garcia [ 03/nov./09 11:09 ]
MDPLVC
Commentaire de Mathilde Caby [ 03/nov./09 16:32 ]
J'ai fait la vérification des deux rapports.

Ils sont tous les deux corrects.
Merci pour cette mise en place
Mathilde




[BIN-167] BI Finance : éclatement du seller bonus en seller bonus et seller malus Création: 10/oct./06 16:51  Mise à jour: 14/sept./07 17:21  Résolue: 10/oct./06 17:57

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Critique
Rapporteur: Agathe Remy Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures

Pays:
FRA - France

 Description   
Une demande complémentaire visant à finaliser le lot 1 du BI Finance :

Les rapports sur les claims intègrent à présent les « seller bonus » ce qui n'étaient pas le cas des rapports sous Titan.

Les « seller bonus » peuvent être soit positifs soit négatifs (par exemple cas d'un vendeur n'ayant pas suffisamment affranchi son colis). Or au moment des compensations seuls les seller bonus positifs (somme dues par PM à un vendeur) sont repris ; les seller bonus négatifs ne sont quant à eux jamais imputés sur les comptes des vendeurs.

Sur le plan financier, on a donc un souci dans la mesure où on constate un produit mais qu'on ne l'encaisse jamais ; il faut donc absolument qu'on arrête de comptabiliser ces seller bonus positifs tant et aussi longtemps que le mécanisme des compensations ne les prendra pas en compte.
Cela nécessite quelques aménagements des rapports portant sur les claims : il faut éclater les colonnes « seller bonus » en deux colonnes distincts : « seller bonus » et « seller malus ».

 Commentaires   
Commentaire de Agathe Remy [ 10/oct./06 17:11 ]
Philippe,
Si je comprends bien ta demande, tu veux que l'on sépare les montants positifs et négatifs du champ seller bonus dans tous les onglets où il apparaît.
Peux-tu me le confirmer ?

Merci.

Agathe
Commentaire de Philippe Favrot [ 10/oct./06 17:20 ]
oui
Philippe
Commentaire de Agathe Remy [ 10/oct./06 17:57 ]
Le rapport Claim status by month avec la distinction seller bonus/seller malus a été livré en Production.

Cordialement,
Agathe




[BIN-240] extraction des personnes ayant fait leur 1ère vente effective sur BI Création: 07/déc./06 16:45  Mise à jour: 14/sept./07 17:32  Echéance: 22/déc./06 00:00  Résolue: 18/déc./06 16:05

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures

Liens des demandes:
Duplicate
doublon de DEC-526 [Routage] : routage du dispositif tes... Fermé
Pays:
FRA - France

 Description   
Hello Agathe,

Nous souhaitons prochainement faire un partir un test sur le coupon vendeur.
Rappel de l'objectif de ce mail : Proposer aux acheteurs qui n'ont pas d'inventaire de découvrir la vente sur PM. On leur attribue un bon d'achat s'ils réalisent une 1ère vente clôturée sur le site.

Le test se déroule donc en plusieurs étapes :
1/ l'acheteur recoit un mail "devenez vendeur et nous vous offrons 3¿ sur un prochain achat" = message 1
2/ le mec dépose des annonces et fait sa 1ère vente
3/ il recoit par email le bon d'achat de 3¿ = message 2

Pb : Il reste encore du boulot pour que ce chantier soit prêt (3 créas à faire + validation du coupon vendeur côté technique) -> le message ne pourra pas partir à temps pour que nous collections les résultats du test sur EMV.
Il faudrait donc que le message parte de chez MM.

Peut-on faire l'extraction de la population de départ sur BI puis voir sur cette population cb de personnes font une 1ère vente effective ? Dans ce cas il faudrait prévoir de faire chaque semaine l'extract des personnes qui ont fait leur 1ère vente effective pour leur envoyer le bon de réduction. Peux-tu me dire si c'est faisable ?

L'idéal serait de faire une réunion sur ce projet. Demain ou lundi, tu serais libre ?

Alexandra

 Commentaires   
Commentaire de Agathe Remy [ 11/déc./06 17:40 ]
Alex,

Petit récap du point fait avec OZA ce matin :
- Pour le 1er envoi du test avec EMV, vous n'avez pas besoin de nous. Il faut en revanche, une fois le mail de test envoyé, nous prévenir afin que nous récupérions les emails des personnes ayant reçu ce mail via Campaign Commander.
- Chaque fin de semaine (jeudi, vendredi?), faire une extraction des personnes ayant reçu le mail de test et ayant réalisées leur premier vente effective : peux-tu nous définir les champs nécessaires (email, user id, pseudo, ...) et les critères de sélection (ayant reçu le mail test et ayant effectué leur première vente effective dans la semaine écoulée, ...)
- Voir avec 1000Mercis comment ils vont pouvoir envoyer les emails d'attribution du coupon et quel format de fichier ils veulent (fichier texte avec séparateur ";", fichier XML, etc...)

Merci:-)

Agathe




[BIN-133] Reporting BI sur les mails automatiques "parrainage" : rapport non parrains et rapport filleuls Création: 11/août/06 15:03  Mise à jour: 14/sept./07 17:18  Résolue: 09/oct./06 12:52

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Salut Agathe,
 
On souhaiterait mettre en place de nouveaux rapports BI sur tous les mails automatiques "parrainage".
Il s'agit de faire une même requête sur BI que sur EMV en regardant la population qui a recu le message de parrainage correspondant (M9 ou M11 dans le cas présent).

1/ Rapport non parrains

Rapport sur la population qui a recu M9-nonparrain-AouV
Population : les non parrains ayant déjà réalisé au moins un achat non annulé à 100% et/ou une vente)
Règle d'envoi : 2 jours après son dernier achat ou sa dernière vente puis tous les 4 mois

Sur EMV :
(where member.BRAND_NAME equals "www" and where member.TOTAL_CHILDREN_COUNT = 0 and where member.PURCHASE_VALID_COUNT = 0 and where member.SALE_CONFIRMATION_COUNT = 1 and where member.IS_NOT_PARENT_SUBSCRIBER = 1 or where member.BRAND_NAME equals "www" and where member.TOTAL_CHILDREN_COUNT = 0 and where member.PURCHASE_VALID_COUNT = 1 and where member.PURCHASE_CANCEL_PERCENT < 100 and where member.SALE_CONFIRMATION_COUNT = 0 and where member.ADVERT_COUNT = 0 and where member.IS_NOT_PARENT_SUBSCRIBER = 1 ) and ( NOT (who received message 245130 ) or NOT (who were sent message 245145 ) or NOT (who were sent message 245146 ))

Nb de parrains total
 Dt nb de parrains A
 Dt nb de parrains V
 Dt nb de parrains A et V
 Dt nb de parrains NANV
Ratio parrains/A ou V
Nb de filleuls
 dont comptes ouverts
 dont comptes contact
Nb de filleuls actifs
 Dont nouveaux acheteurs
 Dont nouveaux vendeurs
 Dont acheteurs-vendeurs
Nb de coupons filleul utilisés
Nb de coupons parrain utilisés
Nb de paniers (avec / sans coupon):
 Valeur articles
 Commission HT
 TVA sur commission
 CA

Périodicité du rapport souhaité : mensuelle


2/ Rapport filleul

Rapport sur la population qui a recu M11-filleuls-NA
Population : filleuls non acheteurs (uniquement depuis le 6 juillet 2004)
Règle d'envoi : 15 jours après être devenu filleul (une fois)

Sur EMV :
M11 relance filleul fil de l'eau ( hors stock initial mai 06)
Condition where member.PARENT_LOGIN is not empty and where member.BRAND_NAME equals "www" and where member.EMVDOUBLON is empty and where member.PURCHASE_VALID_COUNT = 0 and where member.RESENT_CHILD = 0 and where member.ACCOUNT_CREATION_DATE is after 07/06/2004 and where member.USR_TYPE_IDENTIFIER equals "contact" and NOT (who were sent message 1 of series 8913 )

M11 relance filleuls_rattrapage2_DEF
Condition where member.PARENT_LOGIN is not empty and where member.BRAND_NAME equals "www" and where member.EMVDOUBLON is empty and where member.PURCHASE_VALID_COUNT = 0 and where member.RESENT_CHILD = 0 and where member.USR_TYPE_IDENTIFIER equals "equals" and where member.ACCOUNT_CREATION_DATE is after 05/20/2006 03:40 and where member.ACCOUNT_CREATION_DATE is before or on 05/30/2006 00:00

Nb total de filleuls* depuis le début (*personnes ayant le tracking filleul)
Nb total de nouveaux comptes filleuls par mois
Nb de filleuls NA
Nb de comptes ouverts
Nb de comptes contacts
Nb de filleuls actifs depuis le début
 dont A
 dont V
 dont A-V
Nb de filleuls actifs par mois
Nb de paniers (avec / sans coupon):
 Valeur articles
 Commission HT
 TVA sur commission
 CA
Abonnés à au moins une des newsletter (generale, High Tech, Maison & Loisirs)
Abonnés aux offres partenaires
Abonnés à l'automatisation

Périodicité du rapport souhaité : mensuelle

On s'en reparle de vive voix.
Merci
Alexandra


 Commentaires   
Commentaire de Agathe Remy [ 09/oct./06 12:52 ]
Vu avec OSA : le rapport a été livré le 06/10.

Agathe
Commentaire de Mohamed Ezzouak [ 10/oct./06 18:51 ]
Un rapport sur le parrainage a été produit. Il est dans le répertoire personnel de Alexandra.

Le tracking au niveau de la newsletter Parrainage ne pouvant être personnalisé nous ne pouvons obtenir les informations relatives aux nouveaux parrains suites à l'envoi du mail.

Pour l'instant nous produisons des indicateurs synthétiques sur le nombre de parrains/filleuls.




[BIN-540] [BACK-OFFICE] : Créér accès limité à BI dans un dossier donné Création: 07/janv./09 14:01  Mise à jour: 05/févr./09 18:20  Résolue: 05/févr./09 17:59

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Je voudrais mettre à disposition de mon équipe , dans un dossier donné et avec accès limité, quelques requetes prédéfinies que j'aurai créées spécialement.

Ceci pour pallier à certaines choses que le BO ne sait pas faire ou fait mal..
Ou encore pour acceder à des informations archivées et donc plus visibles en BO (ex: evenements)

ex: recherche par IP sans limitation de date
      recherche par adresse de livraison
      recherche de compte par nom & prenom ...

Faire donc en sorte d'arriver dans un dossier donné, sans autre possibilité que de lancer les requetes présentes.

login/mdp proposés: bo / babelstore ( les memes que Back-Office)

Merci d'avance.

 Commentaires   
Commentaire de Dalila Belkebir [ 07/janv./09 19:14 ]
Bonjour Cédric,

Peux -tu me donner plus de précisions STP ?
Veux que ces personnes puissent accéder au répertoire back office existant dans public ou en tout cas à certains rapports "public" ? Veux-tu uniquement leur soumettre des rapports persos que tu auras créés ?

Je te propose de :
- créer un autre User UV Back Office avec un mot de passe spécifique.
- créer un répertoire PUBLIC / BACK OFFICE / Basics
- créer un répertoire PUBLIC / BACK OFFICE / Specific
Ce nouveau User ne verra que le répertoire public / BACK OFFICE / Basics
Le user UV BACK OFFICE aura accès à PUBLIC / BACK OFFICE / Specifics et PUBLIC / BACK OFFICE / Basics
Il te suffira de nous dire quels rapports tu souhaites mettre dans Basics s'il s'agit de rapports publics ou nous dire quels rapports perso tu souhaites envoyer sur la boite de réception du user UV BACK OFFICE

Proposition non contractuelle susceptible de changer mais l'idée est là :-)

Dalila.
Commentaire de Cedric Favero [ 08/janv./09 09:09 ]
Pour les modalités, on voit ensemble mais c'est jute donner accès limité à un dossier prédéfini.
C'est moi ensuite qui y mets les rapports et requetes que je veux mettre à disposition.
Commentaire de Dalila Belkebir [ 08/janv./09 12:07 ]
Cédric,

Je vais travailler dessus le 13/01 pour une mise en production le 15/01. On se voit donc mardi prochain sur les modalités : à 14h ?

Dalila.
Commentaire de Cedric Favero [ 08/janv./09 12:33 ]
çà me va (tu m'envoies l'invite?)
mais vraiment au plus simple, juste créer un accès limité un dossier unique.
Ensuite dedans je pourrai faire des sous-dossiers FR/ES/UK et mettre ce que je veux dedans..

PUBLIC / BACK OFFICE / Basics me va

Merci.
Commentaire de Dalila Belkebir [ 29/janv./09 12:23 ]
Bonjour Cédric,

Juste un petite question non abordée jusque là : souhaites tu autoriser les users à créer des rapports dans leur répertoire perso "mes favoris" ?
Ou bien ne doivent-ils faire que de la visualisation ?

Merci .
Dalila.
Commentaire de Cedric Favero [ 29/janv./09 13:41 ]
Compliqué si on le fait en 2 temps?
D'abord uniquement de la visualisation et du lancement de requetes prédéfinies.
Puis le jour om on veut le faire , on active cette possibilité?
Car dans un premier temps , ceux à qui je laisserais cette lattitude useraient plutot du login ur_backoffice.

Merci.
Commentaire de Dalila Belkebir [ 30/janv./09 16:41 ]
OK je mets juste des droits de visu dans un premier temps. Ensuite, on avisera.

Pour info, MEP prévue mardi midi.

dalila.
Commentaire de Dalila Belkebir [ 05/févr./09 17:59 ]
Cédric,

Les nouveaux éléments sont-ils OK pour toi en prod BI ?
- le nouveau répertoire Bo Working
- le nouvel utilisateur UV Backoffice

merci de ton retour pour clôture du JIRA ?

Cdlt,
Dalila.
Commentaire de Cedric Favero [ 05/févr./09 18:06 ]
Oui c'est tout bon et un tres grand progres pour nous. Merci beaucoup.

Petite question subsidiaire:

Au lieu d'avoir les classiques liens: Historique | Planifier | Modifier | Propriétés
Ne peut on avoir juste un lien "actualiser" ou "lancer" ?

Merci.
Commentaire de Dalila Belkebir [ 05/févr./09 18:20 ]
Cédric,

Je ne pense pas que nous puissions modifier le menu de l'applicatif mais je vais quand même regarder.
Sinon, je te propose d'en faire la suggestion à l'éditeur : Business Object ;-)

Merci de ton retour (et bonne vacances !).


A ta disposition pour vous rendre le BI plus simple.

Cdlt,
Dalila.




[EXP-4581] [Reporting BI] : Pb de performance des requêtes sur TA_USR_EVENT Création: 21/oct./08 12:03  Mise à jour: 25/mars/09 18:15  Résolue: 25/mars/09 18:15

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Bloquant
Rapporteur: Agathe Remy Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File requetes_TA_USR_EVENT.sql    
Pays:
FRA - France

 Description   
Bonjour,

Afin de permettre l'archivage des données de USR_EVENT sur la base OLTP, nous avons rapatrié toutes des données dans notre DataWareHouse (schéma DWH, table TA_USR_EVENT) et nous avons développé un rapport qui permet au BackOffice d'accéder aux évènements d'un pseudo donné.
Nous avons créé cette table avec les mêmes informations de partitionnement que celles définies dans la base OLTP, à savoir par USER_ACCOUNT_ID.
Ce partitionnement nous permet d'avoir des temps de réponse très satisfaisant pour le rapport BackOffice.
En revanche, nous avons de nouveaux besoins de reporting du type "nombre d'évènements d'abonnement à un type d'abonnement entre telle et telle date" ou "liste des descriptions (qui contiennet l'url) des évènements widget". Ces requêtes ne filtrent donc pas le USER_ACCOUNT_ID et leur temps de réponse n'est pas satisfaisant (plus de 5 minutes).
Nous avons essayé de créer un index global sur le type d'évènement (USE_TYPE_CODE), mais nos temps de réponse ne sont toujours pas satisfaisants.
S'il vous plait, pouvez-nous nous aider à optimiser ces requêtes?
Merci.

Agathe

 Commentaires   
Commentaire de Agathe Remy [ 21/oct./08 12:14 ]
Bonjour,

Vous trouverez ci-joint 2 requêtes types dont les temps d'exécution ne sont pas satisfaisants.

A votre dispo si vous avez des question.
Agathe
Commentaire de Ayoub Benseghir [ 28/oct./08 17:06 ]
Bonjour,

Pour la première requête: un hint /*+ no_parallel(TA_USR_EVENT)*/ fait passer le temps d'exécution à 10sec.

Commentaire de Ayoub Benseghir [ 29/oct./08 12:18 ]
Rectification: le no_parallel ne regle pas le problème.
Commentaire de Agathe Remy [ 05/janv./09 11:19 ]
Bonjour,

Suite à la replanification du projet BI Abonnement, la priorité de ce JIRA devient très forte, puisque bloquante pour la livraison du projet.
De plus, nous commençons à avoir des remontées de mécontentement également au niveau du BackOffice.
Voici un exemple de requêtes que nos utilisateurs n'arrivent pas à exécuter en raison de leur trop long temps d'exécution :
SELECT
  DTM.TD_USER_ACCOUNT.LOGIN
FROM
  DTM.TD_USER_ACCOUNT,
  TD_USE_TYPE_CODE,
  TA_USR_EVENT
WHERE
  ( TA_USR_EVENT.USE_TYPE_CODE=TD_USE_TYPE_CODE.USE_TYPE_CODE )
  AND ( TA_USR_EVENT.USER_ACCOUNT_ID=DTM.TD_USER_ACCOUNT.USER_ACCOUNT_ID )
  AND
  (
   TD_USE_TYPE_CODE.LABEL = 'Compensation explicite'
   AND
   TA_USR_EVENT.CREATION_DATE > '01-09-2008 00:00:00'
  )
;

Agathe
Commentaire de Agathe Remy [ 25/mars/09 18:15 ]
Suite aux investigations de Patrick, de nombreuses optimisations sur USR_EVENT ont été mises en place dans la cadre du projet BI Abonnement qui permettent des temps de réponses tout à fait acceptables par les utilisateurs.

Je considère donc ce JIRA comme résolu.
Agathe




Installation Business Objects Production (BIN-15)

[BIN-18] Mise en place du DNS pour la plateforme bi.pricmeinister.com et confapache en PROD Création: 08/déc./05 11:23  Mise à jour: 14/sept./07 16:55  Résolue: 16/déc./05 12:40

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Sébastien Tournay Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 1 heure, 10 minutes
Estimation originale: 1 heure


 Description   
Faire la demande à JMH (MAI) pour demander la création du domaine bi.priceminister.com. On utilise la même VIP que celle de bo.priceminister.com et donc les 2 RIP.

Mettre en place la conf Apache et mod_jk pour attaquer le serveur applicatif BO sur TELLUS (après validation de la préocédure en intégration)

 Commentaires   
Commentaire de Ranto Andriambololona [ 09/déc./05 15:24 ]
Je viens de soumettre dans l'extranet JET la demande pour le domaine bi.priceminister.com et l'ajout des RIP et VIPS

Pour la mise ne place de la conf apache et mod_jk, on le fera le jour où BO sera installé completement et opérationnel sur TELLUS
Commentaire de Ranto Andriambololona [ 16/déc./05 12:40 ]
C'est fait et accessible sur :

http://bi.priceminister.com/businessobjects/enterprise11/

J'ai aussi ajouté une sécurité pour que seul notre IP (Villette) puisse accéder à bi.procmeinister.com






[BIN-118] pas de données sur le rapport BI "new buyers after mailing" avril à juin 2006 Création: 10/juil./06 14:23  Mise à jour: 14/sept./07 17:17  Résolue: 10/juil./06 14:36

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Salut,
en rafrachissant le rapport existant, je n'ai pas de données sur les new buyers after mailing sur la période avril à juin 2006.
Est-ce que tu peux voir ca?
Merci
Alexandra

 Commentaires   
Commentaire de Agathe Remy [ 10/juil./06 14:36 ]
Bonjour,

Tu trouveras le rapport "New buyers after mailing 2006-04/2006-06" rafraichi avec des données (?!) dans le répertoire Favoris/Alexandra.
Te connectes-tu bien à BusinessObjects à l'adresse http://bi.priceminister.com ??? J'ai peur que tu sois connectée au site de développement (http://bi.pm.lan)...

Agathe
Commentaire de Alexandra Viravaud [ 10/juil./06 15:54 ]
j'étais en effet sur une mauvaise adresse :(




Affiliation Programme Vendeur :: Metatache (APP-15282)

[APP-15283] Création d'un état BI pour le suivi du programme Affiliation Vendeur Création: 23/févr./07 14:05  Mise à jour: 25/oct./07 12:48  Résolue: 27/juil./07 15:58

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 17.0.0

Type: Sous-tâche Priorité: Mineur
Rapporteur: Richard Dubois Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Commentaires   
Commentaire de Romain Czornomaz [ 23/févr./07 14:41 ]
Comme convenu ce matin lors de la réunion pour la mise en place du suivi des fraudeurs dans le cadre de l'affiliation vendeurs,
On doit fournir un rapport permettant de suivre les éléments suivants:

- Date de création ou date de publication ( Ghislain doit se renseigner pour savoir quelle date sera utiisée pour les tags affiliations)
- Identifiant de l'annonce
- Statut de l'annonce
- Type de produit
- Prix de vente du produit
- Login du compte vendeur
- Email du compte vendeur
- Mot de passe du compte vendeur
- Adresse IP du compte vendeur


Romain
Commentaire de Romain Czornomaz [ 27/juil./07 15:58 ]
Bonjour,

Les rapports affiliation vendeur sont déployés sur la plateforme BI.

Romain
Commentaire de Ghislain Gridel [ 27/juil./07 17:26 ]
ok. merci.




[APP-15314] BI : Ajout d'un champ CHANGE_DATE dans USR_TRACKING Création: 26/févr./07 15:30  Mise à jour: 25/juin/07 18:49  Résolue: 20/avr./07 15:55

Etat: Fermé
Projet: Application PriceMinister
Composants: Base de données
Affecte la/les version(s): 13.0.0
Version(s) corrigée(s): 14.0.0

Type: Nouvelle fonctionnalité Priorité: Critique
Rapporteur: Agathe Remy Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Classif1: DB
Classif2: bi
Projets PM archivés: Maintenance 14.x.x

 Description   
Bonjour,

Le Marketing ayant le droit de modifier le nom d'un tracking, il faut pouvoir tracer ces modifications afin de les intégrer dans la base de reporting.

Pour cela, pouvez-vous ajouter un champ CHANGE_DATE dans la table USR_TRACKING?

Merci:-)

Agathe

 Commentaires   
Commentaire de Swan Desportes [ 19/mars/07 18:02 ]
Le marketing change les libellés depuis peu mais il n'y a aucun moyen de percevoir cette infomation niveau BI. L'implémentation de cette date est importante pour éviter de casser les rapports.
Commentaire de Alexandre Garnier [ 02/avr./07 18:43 ]
C'est fait
Commentaire de Younès Charrière [ 17/avr./07 18:30 ]
Agathe c'est bon pour toi ?
Commentaire de Ghislain Gridel [ 17/avr./07 18:37 ]
Impec. merci bcp. Ghislain
Commentaire de Agathe Remy [ 18/avr./07 17:23 ]
Le champ CHANGE_DATE n'est pas en NOT NULL comme sur les autres tables...

Est-ce normal? Si oui, pourquoi?

Agathe
Commentaire de Alexandre Garnier [ 18/avr./07 17:31 ]
le script est pourtant bien là : integ/04_POST_DEPLOY/OFFLINE/V14_0_0_APP-15314_BI_ALL_03_add_change_date_usr_tracking.sql

Pas passé ?
Commentaire de Patrick Pereira [ 18/avr./07 17:46 ]
On passe les champ NOT NULL en POST_DEPLOY.
Et donc, non, elle n'est pas encore NOT NULL.
A voir avec l'integ pour le passage des scripts POST_DEPLOY, mais le processus suit son cours.
Commentaire de Younès Charrière [ 20/avr./07 15:02 ]
Peux-tu passer le script en Integ Patrick stp ?
Merci.
Commentaire de Patrick Pereira [ 20/avr./07 15:48 ]
C'est fait en Integ.
Commentaire de Agathe Remy [ 20/avr./07 15:55 ]
C'est OK pour moi.

Agathe




[APP-11459] BI : mise en place d'un flux incrémental sur USR_SUBSCRIPTION Création: 27/juil./06 18:05  Mise à jour: 25/juin/07 18:42  Résolue: 04/août/06 16:18

Etat: Fermé
Projet: Application PriceMinister
Composants: Base de données, News Letters
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 9.0.3

Type: Amélioration Priorité: Critique
Rapporteur: Agathe Remy Attribution: Geneviève Beaujard
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Bonjour,

Afin de permettre la mise en place du partenariat avec 1000Mercis pour les actions Marketing, nous aurions besoin de leur transférer quotidiennement toutes les mises à jour des informations d'abonnement et désabonnement.
Pour éviter de leur transférer toutes les données de la table USR_SUBSCRIPTION tous les jours, nous aimerions bénéficier d'une change_date qui nous indiquerait les modifications (désincriptions) des données.

Merci:-)
Agathe

 Commentaires   
Commentaire de Patrick Condevaux [ 27/juil./06 19:36 ]
qui se charge de ca....
Commentaire de Quentin de Chivré [ 27/juil./06 19:39 ]
USR_SUBSCRIPTION
 Name Null? Type
 ----------------------------------------------------------------------------------- -------- --------------------------------------------------------
 USR_SUBSCRIPTION_ID NOT NULL NUMBER(20)
 USER_ACCOUNT_ID NOT NULL NUMBER(20)
 USS_TYPE_CODE NOT NULL NUMBER(5)
 CREATION_DATE DATE
 ROW_VERSION NUMBER(20)

Je suggère d'ajouter une colonne DELETION_DATE (comme dans COMMISSION_RULE)

Ainsi, lors de la création de compte,
si je m'abonne une newsletter
  => INSERT dans la table
si je ne m'abonne pas
  => rien

Ultérieurement
si je m'abonne une newsletter
  => INSERT dans la table
si je me désabonne
  => UPDATE de DELETION_DATE

Encore plus tard si je me ré-abonne
 =>
1/ nouvel INSERT dans la table,
2/ ou plutot UPDATE de DELETION_DATE a NULL ??

1/ - Permet de garder tout l'historique (mais on l'a dans les evenements aussi)
    - Implique de changer les requetes dans la table (flux EMV, reporting, synchro BI, ....) pour prendre en compte la DELETION_DATE et aussi pour dédoublonner en ne prenant en compte que la ligne la + récente pour un abonnement donné => BOF
2/ - Pas tres clean de de-supprimer une ligne...
    - Implique tjs de changer les requetes dans la table, mais pas de dédoublonnement => Donc mieux
Commentaire de Quentin de Chivré [ 27/juil./06 19:39 ]

Cependant dans ce cas autant plutot faire du classique, a savoir :
 - Ajouter une colonne CHANGE_DATE
 - Ajouter une colonne USS_STATUS_CODE et une table correspondante avec 2 valeurs : SUBSCRIBED, NOT_SUBSCRIBED

Ok c'est un peu lourd mais finalement c'est le plus générique et si jamais on veut rajouter des états ca sera simple (SUSPENDED, ...) et comme ca on reste dans du connu.

Pour le coup on pourrait se demander s'il est utile d'inserer toutes les lignes lors de l'inscription, avec un état SUBSCRIBED ou NOT_SUBSCRIBED mais ca ne me parait pas une bonne idée.



Commentaire de Quentin de Chivré [ 27/juil./06 19:41 ]
Genevieve, peux tu faire ca ? C'est pour Agathe et elle en a besoin pour Septembre (903)
Commentaire de Judd OSullivan [ 31/juil./06 18:15 ]
Donc on garde une ligne dans USR_SUBSCRIPTION même si l'utilisateur n'a plus de subscription.
Et si l'utilisateur abonne il suffit plus d'inserer une ligne. Il faut chercher aussi une ligne existant dans un mode 'NOT_SUBSCRIBED' (d'ailleurs, je prefere SUBSCRIBED et UNSUBSCRIBED).
Commentaire de Quentin de Chivré [ 31/juil./06 18:30 ]
Ok pour le renommage, puisque en effet avec ce mode de fonctionnement on a forcémment été subscribed a un moment
Commentaire de Geneviève Beaujard [ 04/août/06 16:16 ]
hecking in UserDetail.java;
/home/cvs/dev/source/src/com/babelstore/user/UserDetail.java,v <-- UserDetail.java
new revision: 1.42; previous revision: 1.41
done
Checking in userentity.xml;
/home/cvs/dev/source/src/com/babelstore/user/userentity.xml,v <-- userentity.xml
new revision: 1.81; previous revision: 1.80
done
Checking in back/UserSubscribeAction.java;
/home/cvs/dev/source/src/com/babelstore/user/back/UserSubscribeAction.java,v <-- UserSubscribeAction.java
new revision: 1.20; previous revision: 1.19
done
Checking in business/SubscriptionBusiness.java;
/home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusiness.java,v <-- SubscriptionBusiness.java
new revision: 1.1.74.1; previous revision: 1.1
done
Checking in business/SubscriptionBusinessBean.java;
/home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusinessBean.java,v <-- SubscriptionBusinessBean.java
new revision: 1.1.74.1; previous revision: 1.1
done
Checking in business/SubscriptionBusinessHome.java;
/home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusinessHome.java,v <-- SubscriptionBusinessHome.java
new revision: 1.1.74.1; previous revision: 1.1
done
Checking in business/SubscriptionQuery.java;
/home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionQuery.java,v <-- SubscriptionQuery.java
new revision: 1.2.36.1; previous revision: 1.2
done
Checking in business/UserBusinessBean.java;
/home/cvs/dev/source/src/com/babelstore/user/business/UserBusinessBean.java,v <-- UserBusinessBean.java
new revision: 1.476.2.3; previous revision: 1.476.2.2
done
Commentaire de Geneviève Beaujard [ 04/août/06 16:18 ]
Checking in SubscriptionInfo.java;
/home/cvs/dev/source/generated/com/babelstore/user/SubscriptionInfo.java,v <-- SubscriptionInfo.java
new revision: 1.4; previous revision: 1.3
done
Checking in business/BaseSubscriptionInfoQuery.java;
/home/cvs/dev/source/generated/com/babelstore/user/business/BaseSubscriptionInfoQuery.java,v <-- BaseSubscriptionInfoQuery.java
new revision: 1.4; previous revision: 1.3
done
RCS file: /home/cvs/dev/source/generated/com/babelstore/user/business/SubscriptionInfoSelector.java,v
done
Checking in business/SubscriptionInfoSelector.java;
/home/cvs/dev/source/generated/com/babelstore/user/business/SubscriptionInfoSelector.java,v <-- SubscriptionInfoSelector.java
initial revision: 1.1
done
Checking in business/UsrSubscriptionEntityBean.java;
/home/cvs/dev/source/generated/com/babelstore/user/business/UsrSubscriptionEntityBean.java,v <-- UsrSubscriptionEntityBean.java
new revision: 1.6; previous revision: 1.5
done
Checking in business/subscriptionbusiness-ejb-jar-structural.xml;
/home/cvs/dev/source/generated/com/babelstore/user/business/subscriptionbusiness-ejb-jar-structural.xml,v <-- subscriptionbusiness-ejb-jar-structural.xml
new revision: 1.4; previous revision: 1.3
done
Checking in business/subscriptionbusiness-jbosscmp-jdbc.xml;
/home/cvs/dev/source/generated/com/babelstore/user/business/subscriptionbusiness-jbosscmp-jdbc.xml,v <-- subscriptionbusiness-jbosscmp-jdbc.xml
new revision: 1.4; previous revision: 1.3
done
RCS file: /home/cvs/dev/source/generated/com/babelstore/user/code/UssStatusCode.java,v
done
Checking in code/UssStatusCode.java;
/home/cvs/dev/source/generated/com/babelstore/user/code/UssStatusCode.java,v <-- UssStatusCode.java
initial revision: 1.1
done
Commentaire de Judd OSullivan [ 07/août/06 14:26 ]
Certains fichier ont été checkiné sur le branch BRANCH_V902 donc je checkin ces fichiers sur le tronc.

/home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusiness.java,v <-- SubscriptionBusiness.java
new revision: 1.2; previous revision: 1.1
done
Checking in business/SubscriptionBusinessBean.java;
/home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusinessBean.java,v <-- SubscriptionBusinessBean.java
new revision: 1.2; previous revision: 1.1
done
Checking in business/SubscriptionBusinessHome.java;
/home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionBusinessHome.java,v <-- SubscriptionBusinessHome.java
new revision: 1.2; previous revision: 1.1
done
Checking in business/SubscriptionQuery.java;
/home/cvs/dev/source/src/com/babelstore/user/business/SubscriptionQuery.java,v <-- SubscriptionQuery.java
new revision: 1.3; previous revision: 1.2
done
Checking in business/UserBusinessBean.java;
/home/cvs/dev/source/src/com/babelstore/user/business/UserBusinessBean.java,v <-- UserBusinessBean.java
new revision: 1.479; previous revision: 1.478
Commentaire de Quentin de Chivré [ 07/août/06 16:15 ]
Comment eviter cela ? Y a t'il moyen de bloquer les check ins sur une branche une fois celle ci mergée dans le tronc ?

Si on ne peut pas le bloquer, peut etre un petit script pour regarder s'il y a eu des check ins post merge que l'on execute dans les jours qui suivent le merge ?
Commentaire de Judd OSullivan [ 07/août/06 16:50 ]
On peut difficilement bloquer ces check-ins. Mais en même temps c'est une nouvelle manipulation pour les devs donc avec un peu plus d'experience on devrait avoir moins de ce gendre de problème.

Je vais mettre dans notre guide de déploiement une tâche verification des checkins sur le branch après le tag. Le script history_between_tags devrait marcher pour ca.
Commentaire de Patrick Condevaux [ 08/sept./06 15:02 ]
ok en INTEG




[BIN-54] BI : Recall Création: 20/mars/06 13:44  Mise à jour: 14/sept./07 16:58  Echéance: 20/mars/06 00:00  Résolue: 21/mars/06 10:52

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Agathe Remy Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: 55 minutes
Temps consacré: 5 minutes
Estimation originale: 1 heure


 Description   
rapport : New children after mailing
- Onglet "New children after mailing" : libellé de colonne "Contact count" à remplacer par "Contacts count"

rapport : New sellers after mailing
- libellé de colonne "Advert on-line count" à remplacer par "On-line adverts"
- centrer le titre


 Commentaires   
Commentaire de Samir Beghdadi [ 20/mars/06 13:59 ]
C fait
Commentaire de Samir Beghdadi [ 21/mars/06 10:52 ]
C fait




[cob] META-TACHE Fermeture cobs Mobilesachat, Free Surf, France Mobile, Midi Libre, Nice Matin (APP-25098)

[APP-25105] Nettoyage BI après suppression cobs Mobilesachat, Free Surf, France Mobile, Midi Libre, Nice Matin Création: 29/avr./09 19:05  Mise à jour: 02/sept./09 10:00  Résolue: 01/juil./09 12:29

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 52.0.0 (CTN-M)

Type: Sous-tâche Priorité: Mineur
Rapporteur: Fabrice Feugas Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Description   
Nettoyer le code côté BI des cobs cités dans le titre et qui ont été arrêtés.

 Commentaires   
Commentaire de Agathe Remy [ 30/avr./09 11:41 ]
Intégration des emails dans le flux Pn Data prévue pour le flux mensuel du 02/07
Commentaire de Cyril Tanneau [ 01/juil./09 12:29 ]
Bonjour,

les emails des cobrandings inactifs ont bien été intégrés au flux PNDATA.

Merci,

Cyril Tanneau




[INF-182] BI : Accès extérieur pour le téléphone de l'équipe BI Création: 09/oct./08 18:47  Mise à jour: 17/oct./08 14:56  Résolue: 17/oct./08 14:29

Etat: Résolu
Projet: Infrastructure
Composants: Téléphonie
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Bonjour,

Le téléphone de l'équipe (01 42 78 94 61) n'est pas accessible depuis l'extérieur.
Ceci pose un problème à nos partenaires qui ne peuvent doc pas joindre directement l'équipe en cas de besoin :
- l'équipe de développement 1000Mercis a régulièrement besoin de joindre mes développeurs par téléphone;
- les partenaires Assur'One, Pn Data, les chercheurs de Bristol et La Redoute ont également besoin de joindre Dalila régulièrement suite à des incidents ou pour poser des questions sur les évolutions/process.

Merci.
Agathe

 Commentaires   
Commentaire de Stéphane Eccli [ 17/oct./08 14:29 ]
ok
Commentaire de Agathe Remy [ 17/oct./08 14:56 ]
Merci:-)




[DEC-610] [BI] Demande de rapport - nombre de comptes passés de visibilité -1 à 1 suite activation inventaire. Création: 16/oct./07 17:27  Mise à jour: 23/oct./07 10:36  Résolue: 17/oct./07 19:44

Etat: Fermé
Projet: Reporting
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Cedric Favero Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Bug_visibilité_activation_inventairexls.xls    
Pays:
FRA - France

 Description   
Nous avons constaté un bug recemment qui faisait qu'un vendeur créant son compte , tombant en visibilité -1 (par mot clés) pouvait repasser de lui meme en visibilité 1 simplement en activant son inventaire. (APP-17539)

Il est apparu que la procédure d'activation de l'inventaire ne vérifiait pas la visiblité de l'inventaire (resolu en v17)

Ces regles permettant de detecter de nombreuses fraudes ou de comptes suspectés de contrefaçon , il nous faudrait connaitre le nombre de comptes qui ont pu etre concernés sur les 6 derniers mois et nous aurions donc besoin d'un rapport.

Business Objects n'étant pas en mesure de retracer les évenements , je passe par un JIRA pour obtenir un rapport BI dans la mesure du possible.

Les évenements sont donc:

création d'un compte
sellver_visibility passée en -1 par mot clé
envoi du mail d'activation de l'inventaire
validation de l'inventaire par l'utilisateur
passage en 1

ex de compte sur lequel le problème est intervenu: fred12camus

j'insiste sur le fait que le la modification de la visilibté est faite par l'utilisateur et non par le BO sinon on va avoir tous les comptes repassés en 1 manuellement ce qui est notre processus normal.

Merci d'avance.

 Commentaires   
Commentaire de Agathe Remy [ 17/oct./07 10:17 ]
Cédric,

Si je comprends bien, tu veux la liste des comptes repassés en visibilité 1 suite à l'activation de l'inventaire au cours des 6 derniers mois.
Est-ce bien cela?

Agathe
Commentaire de Cedric Favero [ 17/oct./07 10:23 ]
oui c'est bien çà mais il faut qu'ils soient tombés en -1 au préalable.
Car quand tu crées un compte et actives ton inventaire tu passes bien de 0 à 1

Donc en clair:

"comptes passés de visibilité -1 à visibilité 1 suite à l'activation de l'inventaire au cours des 6 derniers mois "
Commentaire de Agathe Remy [ 17/oct./07 19:43 ]
Cédric,

Tu trouveras dans le document ci-joint la liste des 585 user_account_id concernés par ce bug.

Cordialement,
Agathe
Commentaire de Agathe Remy [ 17/oct./07 19:43 ]
La requête effectuée pour extraire la liste des comptes est la suivante :

SELECT DISTINCT user_account.user_account_id
FROM user_account,
     (SELECT creation_date, user_account_id
FROM usr_event
WHERE use_type_code=460
AND description LIKE '-1%'
) hide_event,
(SELECT user_account_id,
creation_date
FROM usr_event
WHERE use_type_code=460
AND description='1 Visible (Surveillé) (Activation)'
) visible_event
WHERE user_account.usr_visibility_code=1 -- visibilité vendeur
AND user_account.usr_activation_code=10 -- inventaire activé
AND user_account.user_account_id=hide_event.user_account_id
AND user_account.user_account_id=visible_event.user_account_id
AND hide_event.creation_date<visible_event.creation_date
;

Agathe
Commentaire de Cedric Favero [ 18/oct./07 09:40 ]
Super.
Après un petit regard , la requete est bonne et c'est exactement ce que je voulais...
Je vais donc pouvoir regarder çà en détail .


Merci beaucoup pour cette grande rapidité.




BI Espagne : environnement de développement (EXP-2886)

[EXP-2898] J'en profite donc pour étoffer la demande en ajoutant la mise en place d'une URL bi.es.dev Création: 27/oct./06 11:27  Mise à jour: 25/juin/07 18:59  Résolue: 27/mars/07 19:27

Etat: Fermé
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Mineur
Rapporteur: Jérémie Bennejean Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Commentaires   
Commentaire de Jérémie Bennejean [ 27/mars/07 18:28 ]
Agathe,

bi.es.dev doit pointer sur quel serveur ?
Commentaire de Agathe Remy [ 27/mars/07 18:58 ]
???




[BIN-236] [Cobrand MidiLibre] Extraction BI Création: 01/déc./06 17:05  Mise à jour: 14/sept./07 17:32  Echéance: 12/janv./07 00:00  Résolue: 30/janv./07 10:35

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Richard Dubois Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Sur la base de la nouvelle remuneration, mettre en place les reports pour GGR

Date de mise en prod possible pour la semaine du 8 au 12 janvier 07

 Commentaires   
Commentaire de Ghislain Gridel [ 01/déc./06 17:13 ]
Les rapports sont à adreser à :

Pour Midi Libre :

agiraudo@midilibre.com

Merci

Ghislain




[EXP-3116] BI : modification de l'alias reporting@priceminister.com Création: 22/déc./06 15:08  Mise à jour: 25/juin/07 19:00  Résolue: 02/janv./07 10:23

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Mineur
Rapporteur: Agathe Remy Attribution: ZZ_Arnaud Baali
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Suite au départ de Moahmed et à l'arrivée de romain, serait-il possible de mettre à jour l'alias reporting@priceminister.com afin d'y remplacer mohamed.ezzouak@priceminister.com par romain.czornomaz@priceminister.com.

Merci:-)

Agathe

 Commentaires   
Commentaire de Patrice Boulanger [ 28/déc./06 10:45 ]
Arnaud,
Merci de voir pour cette demande.
Commentaire de ZZ_Arnaud Baali [ 02/janv./07 10:23 ]
La demande sera active dans la journée




[INF-205] [BI] : Retour de Florian AMBROSI Création: 17/nov./08 11:25  Mise à jour: 04/déc./08 17:46  Résolue: 04/déc./08 17:46

Etat: Résolu
Projet: Infrastructure
Composants: Micro
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Christophe Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word FICHE DE PROFIL FAM - 2008.doc    

 Description   
Bonjour,

Florian AMBROSI, notre stagiaire en alternance les lundis et mardis, est de retour parmi nous jusqu'au 31 mars 2009:-)

S'il te plait, serait-il donc possible de lui donner les droits d'administrateur sur son poste afin qu'il puisse utiliser nos applictifs.
D'autre part, peux-tu vérifier qu'il est bien dans l'alias biteam@priceminister.com ?
Enfin, tu peux récupérer le poste à côté de mon bureau.

Merci.
Agathe
PS : Désolée pour le retard, la semaine dernière fut vraiment trop courte:-( Je ferai mieux la prochaine fois!

 Commentaires   
Commentaire de Stéphane Eccli [ 17/nov./08 11:57 ]
les comptes n'avaient pas été supprimés, je l'ai ajouter a la ML.
reste a voir le compte Jira
Commentaire de Agathe Remy [ 17/nov./08 12:08 ]
Nous avons déjà testé le compte JIRA : c'est ok.
Agathe




[EXP-1195] Envoi de mail Pommery avec BI Création: 07/févr./06 13:16  Mise à jour: 25/juin/07 18:56  Echéance: 08/févr./06 00:00  Résolue: 08/févr./06 15:16

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Pap Ndiaye Attribution: Pap Ndiaye
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 1 heure
Estimation originale: 1 heure





[BIN-113] ajout sur les rapports BI recall Création: 29/juin/06 11:21  Mise à jour: 14/sept./07 17:04  Résolue: 29/juin/06 17:15

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Critique
Rapporteur: Odile Szabo Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures


 Description   
Samir,

peux tu ajouter les nouveaux acheteurs dans le taleau "news buyers after mailing" et les nouveaux vendeurs dans le tableau "news sellers after mailing", mois par mois.

 Commentaires   
Commentaire de Samir Beghdadi [ 29/juin/06 17:15 ]
Je te confirme l'ajout des deux champs "New buyers count" et "New sellers count" dans les deux tableaux respectivement "New buyers after mailing" et "News sellers
after mailing"

Cdt




[EXP-667] BI : demande d'installation de l'ARKOON Création: 22/déc./05 16:55  Mise à jour: 25/juin/07 18:55  Résolue: 23/déc./05 13:05

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Bloquant
Rapporteur: Agathe Remy Attribution: Jérémie Bennejean
Résolution: Corrigé  
Σ Estimation restante: 0 minutes Estimation restante: 0 minutes
Σ Temps consacré: 30 minutes Temps consacré: 30 minutes
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
EXP-669 faire demande MAI à JMH pour certific... Sous-tâche Résolu Ranto Andriambololona  

 Description   
Bonjour,

Serait-il possible d'installer l'ARKOON sur mon poste (demander un certificat à Jet Multimedia) ?!

Merci:-)

Agathe

 Commentaires   
Commentaire de Jérémie Bennejean [ 23/déc./05 13:05 ]
Fais avec le profil d 'emmenuelle lachampe




[EXP-1309] BI : arrivée d'un prestataire Création: 17/févr./06 19:08  Mise à jour: 25/juin/07 18:56  Résolue: 21/févr./06 17:15

Etat: Résolu
Projet: Exploitation
Composants: Installation
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Agathe Remy Attribution: ZZ_Arnaud Baali
Résolution: Corrigé  
Estimation restante: 1 heure
Temps consacré: 3 heures
Estimation originale: 4 heures


 Description   
Comme convenu, voici une demande pour l'installation du poste de Cyrille SARTI d'IDB Consulting pour mercredi 22 février 2006.

Merci.

Agathe

 Commentaires   
Commentaire de ZZ_Arnaud Baali [ 20/févr./06 10:06 ]
Le compte mail est en cours de création




[Cobrand MidiLibre] Metatache (APP-13968)

[APP-13995] [Cobrand MidiLibre] Extraction BI Création: 01/déc./06 16:34  Mise à jour: 25/juin/07 18:47  Résolue: 26/janv./07 16:36

Etat: Fermé
Projet: Application PriceMinister
Composants: Cobrandings
Affecte la/les version(s): 11.1.0 (La Redoute)
Version(s) corrigée(s): 12.0.0

Type: Sub-bug Priorité: Critique
Rapporteur: Richard Dubois Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM archivés: COB Midi Libre

 Description   
Sur la base de la nouvelle remuneration, mettre en place les reports pour GGR

Date de mise en prod possible pour la semaine du 8 au 12 janvier 07

 Commentaires   
Commentaire de Ghislain Gridel [ 01/déc./06 16:48 ]
Les rapports sont à adreser à :

Pour Lycos :

jerome.lepage@lycos-europe.com

Pour Midi Libre :

agiraudo@midilibre.com

Merci

Ghislain
Commentaire de Ghislain Gridel [ 03/janv./07 10:24 ]
Le rapport Midi Libre est un rapport type LRO.

Ghislain
Commentaire de Patrick Condevaux [ 05/févr./07 16:44 ]
ok




[META-TACHE] Projet [VVV] (APP-16788)

[APP-16859] Demande de données BI Création: 29/juin/07 12:30  Mise à jour: 31/juil./07 11:26  Résolue: 30/juil./07 15:16

Etat: Fermé
Projet: Application PriceMinister
Composants: Produits
Affecte la/les version(s): 15.1.2
Version(s) corrigée(s): 16.0.0

Type: Sub-new feature Priorité: Mineur
Rapporteur: Sébastien Aubert Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM archivés: Vendez le vôtre - Vêtement

 Description   
Pour pouvoir avoir une idée du nombre de FP supplémentaires qui seront générées suite à la mise en place du nouveau process, il faudrait connaître le "Nombre moyen de vendeurs différents par FP actives avec annonce"

 Commentaires   
Commentaire de Romain Czornomaz [ 30/juil./07 15:16 ]
Seb,

Alors voici ton resultat du nombre moyen de vendeurs différents ayant des annonces visibles, suspendues, fermées et FP actives:
1.19736621867769408753015310392359572687

En gros ca fait 1 :)

Bonne journée,

Romain
Commentaire de Sébastien Aubert [ 31/juil./07 11:26 ]
ok merci




[META-TACHE] Projet [VVV] (APP-16788)

[APP-18319] Demande de données BI Création: 23/oct./07 11:15  Mise à jour: 21/nov./07 15:40  Résolue: 09/nov./07 16:08

Etat: Fermé
Projet: Application PriceMinister
Composants: Produits
Affecte la/les version(s): 15.1.2, 17.0.0
Version(s) corrigée(s): 18.0.0

Type: Sub-new feature Priorité: Mineur
Rapporteur: Sébastien Aubert Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM archivés: Vendez le vôtre - Vêtement

 Description   
Pour pouvoir avoir une idée du nombre de FP supplémentaires qui seront générées suite à la mise en place du nouveau process, il faudrait connaître le "Nombre moyen de vendeurs différents par FP actives avec annonce"

 Commentaires   
Commentaire de Romain Czornomaz [ 09/nov./07 16:08 ]
Salut,

J'ai refait le calcul pour connaitre le nombre moyen de vendeurs différents par FP actives avec annonce, et j'obtiens desormais... roulement de tanbours... environ 1.15 vendeurs / FP.

Je cloture la demande, n'hesitez pas à la réouvrir Seb ou Benoit si vous souhaitez plus d'infos.

Bonne journée,

Romain





[EXP-2482] BI : le reporting n'a pas démarré ce matin Création: 27/juil./06 16:54  Mise à jour: 25/juin/07 18:58  Résolue: 08/août/06 10:23

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Agathe Remy Attribution: Edouard Laurent
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Le cron a bien lancé le pmreportsconductor.sh, mais il semble que le script de validation de la synchro (/data/priceminister/mafal/pmtopforreports.pl) n'a pas reçu le signal de fin de synchro...
A investiguer...

 Commentaires   
Commentaire de Antoine Koener [ 27/juil./06 18:32 ]

gogogo !




[EXP-2338] BI : accès direct à phaeton depuis latone Création: 26/juin/06 17:54  Mise à jour: 25/juin/07 18:58  Résolue: 27/juin/06 10:40

Etat: Résolu
Projet: Exploitation
Composants: Flux
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 30 minutes
Estimation originale: Non spécifié


 Description   
Bonjour,

Nous aimerions pouvoir accéder directement depuis latone à phaeton sans renseigner à nouveau le mot de passe lorsqu'on fait un ssh adminpm@phaeton.
Ce dispositif est déjà en place sur titan.

Merci:-)
Agathe

 Commentaires   
Commentaire de Jérémie Bennejean [ 27/juin/06 10:40 ]
La demande est en place.
J'ai générée la clé ssh id_dsa.pub sur latone et l'ai mis dans l'authorized_key de phaeton
J'ai testé et montré à François, cela fonctionne.

Jeremie




[BIN-235] [Cobrand Lycos Occasion] Extraction BI Création: 01/déc./06 17:03  Mise à jour: 14/sept./07 17:32  Echéance: 22/déc./06 00:00  Résolue: 05/janv./07 12:40

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Richard Dubois Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Duplicate
a pour doublon APP-13994 [Cobrand] Lycos Occasion Extraction BI Fermé
Pays:
FRA - France

 Description   
Sur la base de l'ancienne remuneration, mettre en place les reports pour GGR

Date de mise en prod prévue pour la semaine du 18 au 22 Décembre.

 Commentaires   
Commentaire de Agathe Remy [ 18/déc./06 17:39 ]
Ghislain,

Peux-tu me communiquer l'adresse email du destinataire?
De plus peux-tu me donner la semaine de premier envoi du rapport (après la mise en prod, sinon pas de données) et me confirmer qu'il s'agit bien du reporting ancienne rémunération?

Merci:-)

Agathe
Commentaire de Ghislain Gridel [ 18/déc./06 18:10 ]
Il faut envoyer le rapport la semaine du 8 janvier à :

jerome.lepage@lycos-europe.com

Il s'agit du rapport ancienne rémunération.

Ghislain
Commentaire de Agathe Remy [ 05/janv./07 12:40 ]
Le reporting hebdo a été mis en place.
Le premier rapport devrait être envoyé dimanche en fin de matinée.

Cordialement,
Agathe




[BIN-234] [Cobrand Lycos Occasion] Extraction BI Création: 01/déc./06 17:03  Mise à jour: 14/sept./07 17:32  Résolue: 04/déc./06 18:44

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Richard Dubois Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Sur la base de l'ancienne remuneration, mettre en place les reports pour GGR

Date de mise en prod prévue pour la semaine du 18 au 22 Décembre.




[INF-25] problème pour genérer les rapports BI - java? Création: 20/nov./07 12:59  Mise à jour: 16/avr./08 17:23  Résolue: 16/avr./08 17:23

Etat: Résolu
Projet: Infrastructure
Composants: Micro
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Henrieta Bubenkova Attribution: Patrice Boulanger
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Bonjour,

J'ai un problème en me connectant à Business Objects, je n'arrive pas à lancer des nouveaux rapports, ça rame et apparemment c'est lié à mon ordinateur car les autres n'ont pas le même souci. Cela peut être du à ma version Java où je ne sais plus, il faut voir. Comme j'ai vraiment besoin de m'en servir régulièrement, c'est assez urgent pour moi.
Merci d'avance.
Henrieta



 Commentaires   
Commentaire de Stéphane Eccli [ 16/avr./08 17:23 ]
demande a refaire si le problème persiste.
Henrieta n'en a pas refait depuis.




[BIN-444] [Affiliation] : Automatisation de rapport BI hebdomadaire Création: 22/mai/08 12:28  Mise à jour: 26/juin/08 15:57  Résolue: 30/mai/08 17:05

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Jonathan Gorges Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Toujours en vue d'optimiser notre productivité, nous voudrions automatiser un rapport en Affiliation.

Il s'agit du rapport "PriceMinister - Affiliation purchase checking" présent ici : Dossiers publics > France > Affiliation.

Voici notre demande :
-> Nous avons besoin de générer 3 rapports automatisés tous les Lundi matin (vers 10h, une fois que les données sont consolidées) en vue de valider les ventes des affiliés.

-> Un rapport pour le Groupe de Tracking : Affiliationx
-> Un rapport pour le Groupe de Tracking : Cibleclickx
-> Un rapport pour le Groupe de Tracking : Zanoxx

La date "Select authorization date" qui nous intéresse est "le mois dernier".
Par exemple : le lundi 19 Mai, le rapport devra couvrir du 18/04 au 18/05.

Je viens vous voir pour en parler de vive voix... (un peu compliqué par Jira j'ai l'impression...).

Merci d'avance pour votre retour.

 Commentaires   
Commentaire de Agathe Remy [ 22/mai/08 20:17 ]
Pas de pb Jonathan:-)

Mais à qui veux-tu les envoyer?

Agathe
Commentaire de Jonathan Gorges [ 23/mai/08 09:22 ]
Hello,

Merci Agathe pour ce retour rapide.

Pour le moment, je voudrais l'envoyer sur mon adresse jonathan.gorges@priceminister.com et sur celle de Ghislain (ghislain.gridel@priceminister.com).

Dès que le nouveau stagiaire prendra ma place :-(... nous changerons mon adresse pour la remplacer par la sienne.

Merci.

Jon.
Commentaire de Cyril Tanneau [ 23/mai/08 12:19 ]
Bonjour Jonathan,

Sous quel format doivent être restitués les rapports (BO, Excel, PDF)?

Merci,

Cyril
Commentaire de Jonathan Gorges [ 30/mai/08 17:16 ]
Merci bcp pour tout ça !

Il manque plus que le nouveau stagiaire maintenant :-) !
Commentaire de Cyril Tanneau [ 02/juin/08 18:07 ]
Le rapport est désormais en production sous le nom "Partner - Affiliation Purchase checking", dans le dossier "France\Affiliation".

Nous lui avons assigné un nouveau nom, afin que le rapport "PM - Affiliation Purchase checking" soit toujours disponible, ce rapport permettant la sélection de la période d'autorisation.

Le rapport est programmé chaque Lundi matin:
- 10h00: Groupe de trackings Zanoxx
- 10h10: Groupe de trackings Affiliationx
- 10h20: Groupe de trackings Cibleclickx.

Les rapports édités seront adressés au format Excel par e-mail à Ghislain (ghislain.gridel@priceminister.com) et Jonathan (jonathan.gorges@priceminister.com). L'objet contiendra: le groupe de trackings, le nom du rapport et la date de rafraichissement.

Merci,

Cyril
Commentaire de Ghislain Gridel [ 03/juin/08 09:34 ]
merci Cyril




[BIN-541] [Marketing] : descriptif "real buyer" sous Bi Création: 07/janv./09 19:25  Mise à jour: 28/janv./09 20:09  Résolue: 09/janv./09 17:21

Etat: Fermé
Projet: Business Intelligence
Composants: Bug & Improvement
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Thomas Beylot Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello
il faudrait plutôt que de dire seulement que real buyer correspond à count of buyer account
préciser que c'est sur du capturé uniquement

merci


 Commentaires   
Commentaire de Cyril Tanneau [ 09/janv./09 17:21 ]
Bonjour,

la description de l'indicateur 'Real buyer count' a bien été modifiée dans les Univers ITEM, PURCHASE et USER ACCOUNT en France et en Espagne.

Nous avons désormais comme description: Buyer count with at least one captured transaction (confirmed by the seller, under claim or closed).

Merci,

Cyril




[EXP-4591] [Alimentation BI] : temps d'attente entre les mappings Création: 27/oct./08 14:49  Mise à jour: 26/nov./08 10:47  Résolue: 26/nov./08 10:47

Etat: Résolu
Projet: Exploitation
Composants: Troubleshooting
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Ayoub Benseghir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: PNG File alim_ODS.png     Microsoft Excel Etude_temps_ALIM_ODS_ITM.xls    
Pays:
FRA - France

 Description   
Bonjour,

Depuis la fin de la semaine dernière, nos durées d'exécution des processflows d'alimentation de l'ODS ont augmenté.
Après analyse, il s'avère que les durées d'exécution des mappings n'ont pas évolué, en revanche le temps d'exécution global du processflow a presque doublé?! Ce sont donc les traitements intermédiaires qui semblent plus longs. Hors nous n'avons à priori aucun levier (en tout cas au niveau de nos développements) sur ces traitements.
Nous n'avons pas touché à ces traitements depuis plus de 2 semaines et ce qui est encore plus étrange, c'est que ce phénomène ne semble toucher que la partie ODS (et non les alimentations DWH et DTM).
S'il vous plait, pourriez-vous nous aider à comprendre ce qui se passe?

Agathe

 Commentaires   
Commentaire de Agathe Remy [ 27/oct./08 14:51 ]
Vous trouverez dans le fichier ci-joint un exemple d'un processflow dont la durée d'exécution a fortement augmenté. Vous pourrez constater qu'il en est de même pour l'alimentation Espagne avec un jour d'avance.

Agathe
Commentaire de Agathe Remy [ 27/oct./08 14:54 ]
Ayoub,

Les processflows sont lancés à partir d'OEM.
Comme vu avec Patrick, peux-tu regarder au niveau d'OEM s'il nous pouvons observer quelque chose?

Merci.
Agathe
Commentaire de Agathe Remy [ 27/oct./08 14:57 ]
Pour information, nous nous sommes d'abord orientés vers un problème de statistiques des schémas RT_FR et RT_ES (sur l'instance DW) qui gèrent les méta-données d'exécutions des mappings et des processflows d'OWB.
De même, nous avons analysé le schéma OWF_MGR sur l'instance OWREP qui contient les méta-données du workflow serveur.

Mais ces actions ont été sans effet sur le problème.

Agathe
Commentaire de Agathe Remy [ 06/nov./08 18:47 ]
Voici une courbe de supervision qui montre bien le problème...

Agathe
Commentaire de Agathe Remy [ 25/nov./08 11:30 ]
En cherchant avec Julien ce qui pouvait se passer entre l'exécution des mappings, nous avons identifier des requêtes sur les méta-données OWB lancées par le workflow server.
Parmi ces requêtes, nous en avons identifier une qui nous semblait particulièrement longue (~40 sec en Prod au lieu de 1 ou 2 sec en Dév) dans le schéma RT_FR sur DW:
SELECT MAX (audit_execution_id)
FROM wb_rt_audit_executions
WHERE ( (parent_audit_execution_id IS NULL AND 5028894 IS NULL)
        OR parent_audit_execution_id = 5028894
       )
   AND external_audit_id = 329829 ;

Il s'avère que cette requête passe par un index (WB_RT_IDX_EX_EK) en Dév et fait un full scan en Prod.
Ce qui est très étrange, c'est que le plan d'exécution proposé par le « set autot trace explain » passe bien par l'index, mais celui de l'exécution fait un full scan.
Nous avons essayé de forcer le passage par l'index en Prod, mais sans succès. Lors de son exécution, la requête fait toujours un full scan ?!!!
Commentaire de Agathe Remy [ 25/nov./08 11:35 ]
Au final, Patrick nous a suggéré de créé un nouvel index à 3 colonnes :
create index WB_RT_IDX_EX_OPT on wb_rt_audit_executions
(external_audit_id, parent_audit_execution_id, audit_execution_id)
compute statistics
tablespace RTS_IX;

Cela fonctionne!!! Nos tests semblent montrer que les temps d'attente ont disparu:-)
J'ai donc créé cet index sur RT_FR et RT_ES.

A vérifier lors de la prochaine alimentation. Nous espérons que solution très pragmatique va résoudre le problème de ce JIRA.

En revanche, nous constatons un phénomène vraiment étrange de décalage entre les plans d'exécutions prévus et ceux réellement exécutés qui rend vraiment compliquée toute optimisation : cf JIRA EXP-4606...
Commentaire de Julien Girardet [ 26/nov./08 10:47 ]
L'alimentation de cette nuit confirme l'utilité de cet index.
Les temps d'attente ont disparu
Je ferme le JIRA

Julien.




[EXP-370] BI : toujours pas de mail pour le consultant Keyrus! Création: 18/nov./05 17:42  Mise à jour: 25/juin/07 18:54  Résolue: 18/nov./05 17:55

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Pap Ndiaye
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Bonjour,

Petit Jira de relance parce qu'Eric Di Bennedetto n'a toujours pas d'email alors que cela fait plus de 3 semaines qu'il est arrivé...
Son email devait être keyrus_owb@priceminister.com.

Merci:-)

 Commentaires   
Commentaire de Pap Ndiaye [ 18/nov./05 17:55 ]
c fait




[EXP-1564] BI : déplacement du poste de Cyrille SARTI Création: 20/mars/06 16:29  Mise à jour: 25/juin/07 18:57  Résolue: 21/mars/06 12:03

Etat: Résolu
Projet: Exploitation
Composants: Installation
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: ZZ_Arnaud Baali
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 15 minutes
Estimation originale: 15 minutes


 Description   
Bonjour,

Serait-il possible de déplacer le poste de Cyrille SARTI à l'une des places libres sur le bureau derrière le nôtre?

Merci:-)

Agathe




[EXP-4583] [Reporting BI] : Optimisation des rapports de cobranding Création: 21/oct./08 18:35  Mise à jour: 12/janv./11 11:12  Résolue: 12/janv./11 11:12

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Ayoub Benseghir
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File cobranding_overview.sql     File cobranding_purchase_sales.sql    
Pays:
FRA - France

 Description   
Bonjour,

Tous les dimanches, nous générons un reporting hebdo à destination de nos partenaires cobranding avec leur activité de la semaine et un récapitulatif des 6 derniers mois.
Certaines requêtes de ces rapports sont trop longues (plus de 10mn).
Nous aimerions donc que vous nous aidiez à optimiser leur durée d'exécution.

Merci pour de nous apporter vos lumières:-)
Agathe

 Commentaires   
Commentaire de Agathe Remy [ 21/oct./08 18:57 ]
Bonjour,

Vous trouverez dans le fichier ci-joint la 1ère requête dont la durée d'exécution est trop longue.

Agathe
Commentaire de Agathe Remy [ 21/oct./08 18:57 ]
Bonjour,

Vous trouverez dans le fichier ci-joint la 2ème requête dont la durée d'exécution est trop longue.

Agathe
Commentaire de Ayoub Benseghir [ 28/oct./08 14:09 ]
Bonjour,

Le seul moyen d'optimiser ces requêtes est de créer un index multicolonne sur TF_ITEM pour chacune d'entre elle (avec ce que ca aura comme conséquence sur l'alim). En même temps 10-15min pour un traitement hebdo généré le dimanche (donc probablement pas utilisé avant lundi) est-ce vraiment grave?

Ayoub
Commentaire de Ayoub Benseghir [ 03/déc./10 12:06 ]
Toujours d'actualité?




[INF-616] Besoin pc au BI pour install BO Création: 14/janv./11 14:47  Mise à jour: 26/janv./11 15:11  Résolue: 26/janv./11 15:11

Etat: Résolu
Projet: Infrastructure
Composants: Micro
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Julien Girardet Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Hello,

Comme discuté à l'instant, j'ai besoin d'un pc (temporairement) pour installer le client BO le temps de la migration de Business Objects R3.1, c'est à dire pendant Q1.

Merci
Julien.


 Commentaires   
Commentaire de Stéphane Eccli [ 26/janv./11 15:11 ]
done.




[Cobrand] Lycos Occasion metatache (APP-13834)

[APP-13994] [Cobrand] Lycos Occasion Extraction BI Création: 01/déc./06 16:31  Mise à jour: 25/juin/07 18:47  Résolue: 03/janv./07 09:46

Etat: Fermé
Projet: Application PriceMinister
Composants: Cobrandings
Affecte la/les version(s): 11.2.0 (Lycos)
Version(s) corrigée(s): 11.2.0 (Lycos)

Type: Sub-bug Priorité: Mineur
Rapporteur: Richard Dubois Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Duplicate
doublon de BIN-235 [Cobrand Lycos Occasion] Extraction BI Fermé
Pays:
FRA - France
Projets PM archivés: COB Lycos

 Description   
Sur la base de l'ancienne remuneration, mettre en place les reports pour GGR

Date de mise en prod prévue pour la semaine du 18 au 22 Décembre.




[Suppression COB] BambinOccasion et VirginMega (APP-15134)

[APP-15585] Arrêt des envois et suppression des rapports BI Création: 20/mars/07 11:37  Mise à jour: 06/sept./07 17:49  Résolue: 30/mars/07 14:12

Etat: Fermé
Projet: Application PriceMinister
Composants: Cobrandings
Affecte la/les version(s): Aucune
Version(s) corrigée(s): ToDo

Type: Sub-bug Priorité: Mineur
Rapporteur: Richard Dubois Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Projets PM archivés: COB Suppression COB obsolètes

 Description   
Agathe,

merci (si ce n'est pas déjà fait) d'arréter d'envoyer les rapports pour BambinOccasion et VirginMega.

Merci




[APP-18364] BI : Mise en ligne d'offre d'emploi Création: 29/oct./07 11:28  Mise à jour: 05/nov./07 15:34  Résolue: 05/nov./07 15:34

Etat: Fermé
Projet: Application PriceMinister
Composants: Aide en ligne, Infoglue
Affecte la/les version(s): 17.1.1
Version(s) corrigée(s): 17.2.0

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Olga Costa
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word Ciblage Emailing.doc     Microsoft Word Concepteur Developpeur BI.doc    
Pays:
FRA - France

 Description   
Bonjour,

Voici 2 offres d'emploi que j'aimerais diffuser sur le site dans la rubrique « PriceMinister recrute ».

Merci:-)

Agathe

 



 Commentaires   
Commentaire de Ariane Baldinger [ 30/oct./07 10:14 ]
Olga,
Peux-tu t'en occuper stp ?
Commentaire de Olga Costa [ 31/oct./07 11:57 ]
Agathe, j'ai mis les annonces.
Tu peux les voir ici http://bo.pm.bollinger:3180/help?action=c
Si c'est ok pour toi, je soumets à publication.
Merci




[APP-18584] BI : règle de calcul du prix conseillé Création: 20/nov./07 11:52  Mise à jour: 26/nov./07 07:52  Résolue: 23/nov./07 10:12

Etat: Fermé
Projet: Application PriceMinister
Composants: Produits
Affecte la/les version(s): 17.2.1
Version(s) corrigée(s): 18.0.0

Type: Nouvelle fonctionnalité Priorité: Critique
Rapporteur: Agathe Remy Attribution: Geneviève Beaujard
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***
Classif1: MEV

 Description   
Bonjour,

Dans le cadre de la mise en place de la campagne CRM "Mise en vente trop chère, trop longtemps", le Marketing a défini un critère de ciblage "annonce dont le prix de vente est supérieur au montant de la transaction moyenne observée depuis 6 mois".

Nous aimerions donc savoir si ce "montant de la transaction moyenne observée depuis 6 mois" est stocké dans la base de données et quelles sont les régles de calcul associées.

Pourrait-on avoir les mêmes informations pour le prix de vente conseillé?

Merci:-)

Agathe

 Commentaires   
Commentaire de Geneviève Beaujard [ 23/nov./07 10:12 ]
Nous aimerions donc savoir si ce "montant de la transaction moyenne observée depuis 6 mois" est stocké dans la base de données et quelles sont les régles de calcul associées:
Non ce montant n'est pas stocké dans la base.
Il est calculé dans BaseProductModel dans la variable mAvgSalePrice:
- lors de la soumission d'annonces (MEV rapide) à partir d'une fiche produit
- lors de la creation d'un souhait
- lors de la soumission d'opinions (calcul non exploité)
Ce montant depend de 2 propriétés:
'priceminister.suggested_price.number_of_months' indique le nombre de mois sur lequel on va calculé la transaction moyenne (valeur par defaut 6 mois)
'priceminister.suggested_price.min_count' indique le nombre minimum de transactions pour calculer une moyenne (valeur par defaut 3)
SI le nbre de transactions effectuées sur les 'priceminister.suggested_price.number_of_months' mois est superieur à 'priceminister.suggested_price.min_count'
ALORS mAvgSalePrice = moyenne des transactions sur les x derniers mois
SINON SI le nbre de transactions effectuées est superieur à priceminister.suggested_price.min_count
ALORS mAvgSalePrice = moyenne des transactions
SINON mAvgSalePrice = moyenne des transactions


Pourrait-on avoir les mêmes informations pour le prix de vente conseillé?
Ce calcul se fait en plusieurs etapes
Prix de vente conseillé (suggested_price):
1) on tient compte du meilleur prix
Ce montant depend de la propriété:
'priceminister.suggested_price.reduction_ratio_best_price' (valeur par defaut à.9)

SI le produit a un meilleur prix (best_price)
ALORS {
        suggested_price_1 = ratio_best_price * best_price
        SI suggested_price_1 > 0.5*list_price ALORS suggested_price_1 = 0.5*list_price

2) on tient compte du montant de la transaction moyenne observée depuis x mois
calcul de mAvgSalePrice (different de l'explication précédente)
Ce montant depend de 2 propriétés:
'priceminister.suggested_price.number_of_months' indique le nombre de mois sur lequel on va calculé la transaction moyenne (valeur par defaut 6 mois)
J'appelle cette propriété nbMonth
'priceminister.suggested_price.min_count' indique le nombre minimum de transactions pour calculer une moyenne (valeur par defaut 3)
'priceminister.suggested_price.reduction_ratio_avg_sale_price' (valeur par defaut 0.95)
J'appelle cette propriété ratio_2

// calcul de mAvgSalePrice
SI le nbre de transactions effectuées sur les 'nbMonths' mois est superieur à 'min_count' ALORS mAvgSalePrice = moyenne des transactions sur les x derniers mois
SINON SI le nbre total de transactions effectuées est superieur à priceminister.suggested_price.min_count ALORS mAvgSalePrice = moyenne des transactions
SI mAvgSalePrice IS NOT NULL ALORS suggested_price_2 = ratio_2 * mAvgSalePrice

// calcul de suggested_price
SI suggested_price_1 IS NULL || suggested_price_2 < suggested_price_1 ALORS suggested_price = suggested_price_2
       
3) on tient compte des souhaits sur ce produit
SI suggested_price IS NULL ALORS suggested_price = la valeur moyenne des souhaits

4) test du montant de suggested_price
SI suggested_price < prix_minimum ALORS suggested_price = prix_minimum

En bref le "montant de la transaction moyenne observée depuis 6 mois" n'est pas stocké dans la base de données.
Je donne donc les régles de calcul associées:
Voici la requête effectuée:
SELECT
  AVG(CASE WHEN creation_date > :date
           THEN toEuro(item_cost_price + item_fixed_commission_net + item_fixed_commission_tax +
                       item_varia_commission_net + item_varia_commission_tax, currency_id)
           ELSE NULL END) AS average_recent,
  COUNT(CASE WHEN creation_date > :date THEN 1 ELSE NULL END) AS count_recent,
  AVG(toEuro(item_cost_price + item_fixed_commission_net + item_fixed_commission_tax
           + item_varia_commission_net + item_varia_commission_tax, currency_id)) AS average_global,
  COUNT(*) AS count_global
FROM item
WHERE (product_id = :x3)
AND (itm_status_code = 40)

la variable date etant SYSDATE - le nombre de mois fixé dans la propriété 'priceminister.suggested_price.number_of_months'

la valeur moyenne sur les x derniers mois est:
average_recent / count_recent
cette valeur moyenne n'est prise en compte que si le nombre de transactions est superieure a la propriété 'priceminister.suggested_price.min_count'
Commentaire de Geneviève Beaujard [ 23/nov./07 10:34 ]
Cette demande de renseignement m'amene a poster le bug http://pricejira.lan/browse/APP-18650
Commentaire de Geneviève Beaujard [ 26/nov./07 07:52 ]
rectificatif:
la valeur moyenne des transactions sur les x derniers mois est:
average_recent
cette valeur moyenne n'est prise en compte que si le nombre de transactions est superieure a la propriété 'priceminister.suggested_price.min_count'
Il existe une valeur moyenne globale:
average_global

calcul de la valeur moyenne des souhaits pour un produit:
1) on effectue la requête suivante:
VAR x1 NUMBER § EXEC :x1 := n° produit;
SELECT MAX(creation_date) AS creation_date,
           COUNT(*) AS count,
           MIN(buy_price) AS min,
           MAX(buy_price) AS max,
           AVG(buy_price) AS average
FROM wish
WHERE (product_id = :x1)
AND (wsh_type_code = 10) -- normal
AND (wsh_status_code = 10) -- open

2) la valeur moyenne d'un souhait (calculée dans Pricer.java) est:
SI (count > 4 && average != null)
ALORS valeur_moyenne = (average * count - min - max) / (count - 2)




[Suppression COB M6] Metatache (APP-15115)

[APP-15909] Arrêt des envois et suppression des rapports BI Création: 11/avr./07 15:28  Mise à jour: 10/juil./07 15:01  Résolue: 11/avr./07 16:19

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 15.0.0

Type: Sous-tâche Priorité: Mineur
Rapporteur: Richard Dubois Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Projets PM archivés: Maintenance 15.x.x

 Commentaires   
Commentaire de Agathe Remy [ 11/avr./07 16:19 ]
Déjà traité!

Agathe




Informations complémentaires à intégrer dans le rapport "panier_coupon_article" (DEC-395)

[DEC-398] BI : mettre à jour le rapport Finance Purchases summary Création: 19/juil./06 16:18  Mise à jour: 14/sept./07 14:45  Résolue: 11/oct./06 14:17

Etat: Fermé
Projet: Reporting
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures





[EXP-2481] BI : Le share NFS de titan sur junon ne fonctionne plus Création: 27/juil./06 16:52  Mise à jour: 25/juin/07 18:58  Résolue: 28/juil./06 09:56

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Bloquant
Rapporteur: Agathe Remy Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Il semble que le share NFS de titan sur junon n'a pas été remonté suite au crash d'hier?!

Merci:-)

Agathe

 Commentaires   
Commentaire de Antoine Koener [ 28/juil./06 09:54 ]
Ca refonctionne ?
Commentaire de Agathe Remy [ 28/juil./06 09:56 ]
Tout est OK:-)

Merci!




[BIN-126] [Cobranding] Infobébé : Mettre en place le reporting su BI Création: 02/août/06 10:38  Mise à jour: 22/oct./07 10:08  Résolue: 22/oct./07 10:08

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Ghislain Gridel Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Agathe,

il s'agit de mettre en place le reporting du co-branding Infobébé. Ce n'est apparemment pas un co-branding en tant que tel. Il comprend les catégories produits jouets et puériculture.

J'ai besoin des données suivantes :

- New Buyer
- New seller
- Purchases
- Items
- Captured cost price
- Commission amount without shipping
- VAT on commission without shipping

Merci.

Ghislain

 Commentaires   
Commentaire de Ariane Baldinger [ 03/août/06 11:40 ]
il y a eu erreur sur la personne ...
Commentaire de Ghislain Gridel [ 12/mars/07 10:46 ]
Agathe,

des nouvelles de ce JIRA ?
Commentaire de Agathe Remy [ 12/mars/07 11:33 ]
Ghislain,

Nous venons de mettre en place un grand nombre de rapports pour toi et il me semble que tu as d'autres demandes plus urgentes (ex : cobranding auto)...
A quoi cela sert-il de mettre la pression sinon générer des tensions?

Agathe
Commentaire de Agathe Remy [ 25/sept./07 14:07 ]
Ghislain,

Olivier nous a annoncé que nous allions abandonner le partenariat InfoBébé.
Ainsi, il me semble que ce JIRA devient obsolète.

Pourvons-nous le fermer?

Merci.

Agathe
Commentaire de Ghislain Gridel [ 15/oct./07 17:09 ]
Bonjour,

il faudrait aussi désactiver les rapports envoyés à Infobébé car ce partenriat n'est plus actif..

Merci.

Ghislain
Commentaire de Agathe Remy [ 22/oct./07 10:08 ]
C'est fait.




[BIN-209] BI Espagne / rapport complémentaire (seller debt) Création: 26/oct./06 17:14  Mise à jour: 14/sept./07 17:31  Résolue: 07/févr./07 11:53

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Philippe Favrot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne

 Description   
Rapport à mettre en place sur la partie Espagne (non encore listé à ce jour - sauf erreur de ma part) : rapport déterminant la dette vendeur

ce rapport existe pour la France : cf. Titan confid / executive / seller_debt

avant de te lancer dans les développements parlons en 5 minutes pour bien valider que le rapport Titan est correct (je n'en suis pas persuadé).

Philippe

 Commentaires   
Commentaire de Agathe Remy [ 31/oct./06 11:13 ]
Les règles de gestion du rapport sont les suivantes :
- transaction confirmée par le vendeur
- date d'autorisation du panier strictement inférieure au mois considéré
- date de paiement de la compensation supérieure ou égale au mois considéré ou pas de date de paiement de la compensation
- transaction non abandonnée

Les informations fournies sont les suivantes :
- date d'autorisation du panier
- identifiant du panier
- identifiant de la transaction
- statut de la transaction
- prix de l'article (cost price)
- commission nette sur article (fixe+variable)
- TVA sur commission article
- montant des frais de ports (cost price)
- commission nette sur frais de port
- TVA sur commission frais de port
- date de paiement de la compensation
- statut de la compensation
Commentaire de Philippe Favrot [ 08/nov./06 13:13 ]
Agathe,
merci pour ces précisions.
je voudrais creuser avec toi les trois éléments suivants :
    "statut de la transaction"
    "date de paiement de la compensation"
    " statut de a compensation".
A ta disposition
Merci
Philippe
Commentaire de Agathe Remy [ 29/nov./06 12:16 ]
Je viens de regarder pour les statuts de compensation. Il n'en existe que 2!
10 : Compensation ouverte (Open, any item or claim can be added)
40 : Compensation fermée (Compensation closed, no more items can be added)

Agathe




[BIN-409] [Centralisation PMV] : Etude des impacts de la V19 sur les rapports BI Création: 13/févr./08 15:34  Mise à jour: 29/avr./08 17:31  Echéance: 29/févr./08 00:00  Résolue: 29/avr./08 17:26

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Agathe Remy Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Romain,

Pourrais-tu faire l'analyse des impacts possibles de l'activation des vendeurs en mode PLATINE sur les rapports PMV (financiers et marketing)?

Merci.

Agathe

 Commentaires   
Commentaire de Romain Czornomaz [ 03/mars/08 17:40 ]
Agathe,

Le document sur les impacts est à valider.

Merci d'avance,

Romain
Commentaire de Agathe Remy [ 12/mars/08 10:58 ]
Dans le rapport TITAN des opérations de février, cf fichier ci-joint, les opérations des 25 et 26 février liées à la migration (onglet « Data (3) » surlignées en jaune - onglet « summary » surlignées en orange)
ont été générées dans « DEBIT_TRANSFER » et « DEBIT_CHECK ».
La contrepartie de ces opérations se trouve au crédit dans « CREDIT_COMPENSATION ». (je pense qu'il s'agit des compensations par chèque et par virement antérieures à la migration)

25/2/2008 DEBIT_TRANSFER 69 044.74
25/2/2008 DEBIT_CHECK 4 871.14
26/2/2008 DEBIT_TRANSFER 390.60

La migration ne doit pas avoir d'impact dans les mouvements du PMV, ces opérations doivent donc être toutes constatées au crédit dans « CREDIT_COMPENSATION »

Ou bien alors les constater (au débit comme au crédit) dans une nouvelle « cause » qui pourrait être par exemple « MIGRATION ...», elles seraient alors isolées des autres mouvements du PMV.

Il faut donc effectuer une correction sur les opérations des 25 et 26 février concernées.

Si ce n'est pas très clair et si tu as besoin de précisions, n'hésite pas à revenir vers moi.

Claudie




[EXP-4606] [BI Prod] : problème de plan d'exécution sur latone Création: 05/nov./08 16:42  Mise à jour: 23/mars/09 16:31  Résolue: 23/mars/09 16:31

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Agathe Remy Attribution: Ayoub Benseghir
Résolution: Impossible à reproduire  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour Ayoub,

Depuis hier, les plans d'exécution de nos requête sur latone ne correspondent plus du tout aux plans réels lors de l'exécution de la requête.
De plus, j'ai un message :
 'PLAN_TABLE' is old version

As-tu une idée de ce qui se passe?

Merci pour ton aide.

Agathe

 Commentaires   
Commentaire de Ayoub Benseghir [ 27/nov./08 11:37 ]
Le message 'PLAN_TABLE' is old version n'est pas grave.
Pour les plans d'exécution ca vient peut être des profils qui étaient activés, avez-vous toujours le problème depuis que Patrick les a désactivés?
Commentaire de Ayoub Benseghir [ 09/déc./08 10:30 ]
Pouvez-vous me fournir une requête de test svp
Commentaire de Ayoub Benseghir [ 12/mars/09 15:40 ]
Est-ce que le problème est toujours d'actualité?




[INF-206] [BI] : Besoin de powerpoint sur le poste de Julien GIRARDET Création: 18/nov./08 11:55  Mise à jour: 21/nov./08 10:45  Résolue: 21/nov./08 10:38

Etat: Résolu
Projet: Infrastructure
Composants: Micro
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Bonjour Stéphane,

Julien doit préparer une présentation PowerPoint pour Justin.
Pourrais-tu lui installer PowerPoint?

Merci.
Agathe

 Commentaires   
Commentaire de Stéphane Eccli [ 21/nov./08 10:38 ]
ok
Commentaire de Julien Girardet [ 21/nov./08 10:45 ]
Merci Stéphane




[EXP-4614] [Alimentation BI] : erreur quotidienne dans l'analyse de l'ODS Création: 13/nov./08 19:22  Mise à jour: 10/sept./09 14:52

Etat: Ouvert
Projet: Exploitation
Composants: Comptage
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Suite à l'incident d'aujourd'hui, nous venons d'identifier une erreur quotidienne dans l'analyse du schéma ODS dans les fichiers :
/appli/oracle/admin/DW/bdump/
*** SERVICE NAME:(DW) 2008-11-13 01:38:16.518
*** SESSION ID:(179.30746) 2008-11-13 01:38:16.518
*** 2008-11-13 01:38:16.518
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [rworupo.1], [4092], [4000], [], [], [], [], []
Current SQL statement for this session:
select min(minbkt),maxbkt,substrb(dump(min(val),16,0,32),1,120) minval,substrb(dump(max(val),16,0,32),1,120) maxval,sum(rep) sumrep, sum(repsq) sumrepsq, max(rep) maxrep, count(*) bktndv, sum(case when rep=1 then 1 else 0 end) unqrep from (select val,min(bkt) minbkt, max(bkt) maxbkt, count(val) rep, count(val)*count(val) repsq from (select /*+ parallel(t,16) parallel_index(t,16) dbms_stats cursor_sharing_exact use_weak_name_resl dynamic_sampling(0) no_monitoring */substrb("SUBMITTER_COMMENT",1,32) val, ntile(254) over (order by nlssort(substrb("SUBMITTER_COMMENT",1,32),'NLS_SORT = binary')) bkt from "ODS"."PRODUCT" t where substrb("SUBMITTER_COMMENT",1,32) is not null) group by val) group by maxbkt order by maxbkt

Pouvez-vous nous aider à la résoudre?

Merci.
Agathe

 Commentaires   
Commentaire de Agathe Remy [ 13/nov./08 19:24 ]
Pour info, voici l'ordre d'analyse que nous lançons:
dbms_stats.gather_schema_stats(Ownname=>'ODS',estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE,method_opt=>'FOR ALL COLUMNS SIZE AUTO',cascade=>DBMS_STATS.AUTO_CASCADE,granularity=>'ALL', options=>'GATHER AUTO');

A votre dispo.
Agathe
Commentaire de Patrick Pereira [ 09/déc./08 11:34 ]
Après plusieurs tests avec le gather_schema_stats, je ne parviens pas à éviter l'erreur.

Je vous propose donc de remplacer l'appel à la procédure précédente par l'appel suivant, dans le cas d'ODS :
 

begin
for tab in (select table_name
            from all_tables at
            where owner='ODS'
            and table_name not in (
                                   select table_name
                                   from all_external_tables ext
                                   where owner='ODS'
                                   and ext.table_name = at.table_name
                                   )
           )
loop
   DBMS_STATS.GATHER_TABLE_STATS('ODS',tab.table_name,NULL, 1, FALSE, 'FOR ALL INDEXED COLUMNS', NULL, 'default', FALSE);

   for idx in (select index_name
               from all_indexes
               where owner='ODS'
               and table_name = tab.table_name
              )

   loop
         DBMS_STATS.GATHER_INDEX_STATS
                ('ODS',idx.index_name,NULL,DBMS_STATS.AUTO_SAMPLE_SIZE,NULL,NULL,NULL,DBMS_STATS.DEFAULT_DEGREE, 'ALL', FALSE);
   end loop;

end loop;

end;
/

 
J'ai testé l'opération sur Latone.
Elle a fonctionné sans problème en 1m50s.

Qu'en pensez-vous ?
Commentaire de Patrick Pereira [ 13/janv./09 16:07 ]
Ou en sommes-nous ?
Commentaire de Agathe Remy [ 10/sept./09 14:52 ]
Si tu as du temps...




[EXP-1735] Ralentissement apllication BI java à cause de l'antivirus Création: 07/avr./06 09:55  Mise à jour: 25/juin/07 18:57  Résolue: 07/avr./06 10:14

Etat: Résolu
Projet: Exploitation
Composants: Maintenance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Mohamed Ezzouak Attribution: ZZ_Arnaud Baali
Résolution: Corrigé  
Estimation restante: 15 minutes
Temps consacré: Non spécifié
Estimation originale: 15 minutes


 Description   
Bonjour,

L'antivirus Kaspersky ralenti l'application Java de Business Objects pour les utilisateurs suivants : François Rousseau & Romain Gajac.
Peux-tu désactiver le scan sur les applications Java pour éviter ce type de ralentissement.

Merci.

Mohamed Ezzouak

 Commentaires   
Commentaire de ZZ_Arnaud Baali [ 07/avr./06 10:14 ]
L'application Java a été iniorée sur les postes de tout le marketing




[BIN-168] BI Finance : purchases summary by month Création: 10/oct./06 16:54  Mise à jour: 14/sept./07 17:21  Résolue: 01/déc./06 17:10

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Critique
Rapporteur: Agathe Remy Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 4 heures
Temps consacré: Non spécifié
Estimation originale: 4 heures

Pays:
FRA - France

 Description   
Est il possible de compléter ce rapport des informations suivantes :

1 - le tableau tel qu'il est présenté ne permet pas de savoir, pendant les 5 / 6 premiers jours du mois (m+1), si les chiffres au titre du VA capturé et des commissions du mois m sont finaux où s'ils sont provisoires du fait de transactions potentiellement toujours dans un statut transitoire pendant ce laps de temps (en revanche le VA autorisé du mois m, donné par BO le 1ier jour du mois (m+1), doit être définitif et ne doit en principe plus varier).
Il serait utilise d'indiquer dans un cadre sous le tableau de bord tel qu'il est présenté (voir 1ier onglet du fichier excel joint) les deux chiffres suivants :
- montant des paniers annulés ;
- montant des paniers en suspens.
(de cette manière on saura lorsque le montant des paniers en suspens est à 0 que les chiffres de commissions et de VA capturé sont définitifs).

 2 - Par ailleurs, j'ai un fichier excel dans lequel je saisis tous les jours le VA ressortant du BO que je compare par rapport au même mois de l'année précédente en cumul depuis le début du mois ; par ailleurs à l'aide de diverses règles de trois (en particulier pour tenir compte du fait que le VA du BO est toujours supérieur au VA autorisé réel) j'en déduis un VA autorisé et capturé pour l'ensemble du mois que je compare à l'objectif ; tout ceci est un peu long et doit pouvoir être automatisé avec BO dans la mesure ou les données sont disponibles dans BO.
L'idéal serait de pouvoir créer un second onglet selon le format du fichier excel joint (onglet : daily authorized GMS).

 Commentaires   
Commentaire de Agathe Remy [ 11/oct./06 12:34 ]
en suspens = REQUESTED ou OBSERVATION
Commentaire de Philippe Favrot [ 11/oct./06 13:50 ]
Oui
Philippe
Commentaire de Agathe Remy [ 02/nov./06 14:52 ]
Le point 1 a été mis en place :
tu trouveras dans le tableau de bord deux nouvelles lignes :
Cancelling amount
Pending amount

Agathe
Commentaire de Philippe Favrot [ 03/nov./06 09:03 ]
c'est nickel
merci
Philippe




[BIN-337] [Exploitation] : procédure d'arrêt / démarrage de la plate-forme BI Création: 30/mai/07 17:35  Mise à jour: 29/janv./08 17:52  Echéance: 08/juin/07 00:00  Résolue: 02/janv./08 11:23

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Stéphane Boulanger Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Procédure d'arrêt/démarrage des serveurs de production suivants : TITAN / LATONE / TELLUS (j'en ai oublié peut être?)

L'idée est de documenter l'arrêt / démarrage des différents composants de la plate-forme de production décisionnelle.

Il faudra notamment retrouvé les points suivants :

- pre-requis
- contraintes (plages horaires et dates où l'on ne peux pas arrêter la plate-forme)
- dépendances entre les différentes composantes
- ordre d'arrêt / démarrage
- commandes utilisées (avec le nom d'utilisateur habilité à faire ces opérations)

Merci d'avance.



 Commentaires   
Commentaire de Agathe Remy [ 02/janv./08 11:23 ]
cf les documents suivants dans le répertoire V:\Reporting\BusinessIntelligence\Exploitation:
- Procédure d'exploitation de l'alimentation.doc
- Désactivation de l'alimentation V2.doc
- Exploitation BO production.doc

Patrice, puis-je fremer la demande?

Merci:-)

Agathe




[BIN-53] BI : Recall : New buyers after mailing Création: 17/mars/06 14:42  Mise à jour: 14/sept./07 16:58  Echéance: 17/mars/06 00:00  Résolue: 21/mars/06 10:54

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Bloquant
Rapporteur: Agathe Remy Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: 45 minutes
Temps consacré: 15 minutes
Estimation originale: 1 heure


 Description   
- Le résultat des colonnes "Purchases" et "Net merchandise sold" ets identique?!
- La dernière colonne doit être "Net commission" et non "Shipping commission"
- Remplacer les noms de colonne "Buyers" par "Buyers count" et "Purchases" par "Purchases count" (je sais, je reviens en arrière, mais l'erreur est humaine;-)
- Faire tenir le rapport sur une page A4 en format rapport (la colonne "Shipping commission" passe sur une deuxième page).


 Commentaires   
Commentaire de Samir Beghdadi [ 17/mars/06 18:30 ]
C bon pour les trois rapports.




[EXP-783] Mise en place d'une sauvegarde de LANSON pour BI Création: 05/janv./06 12:39  Mise à jour: 25/juin/07 18:55  Echéance: 12/janv./06 00:00  Résolue: 12/janv./06 12:05

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Sébastien Tournay Attribution: Pap Ndiaye
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 4 heures
Estimation originale: 4 heures


 Description   
Intégrer dans notre boucle de sauvegarde quotidienne la sauvegarde des instances BOREP, OWREP et WKFREP de LANSON. Prévoir de faire cela base fermée (à confirmer avec Edouard) pour prendre l'ensemble des fichiers de données et les différents controls files. S'assurer de la nécessité de prendre d'autres fichiers.

voir s'il est possbile de mettre cela sur la même bande de sauvegarde au moment ou l'on passe déjà sur LANSON pour ramasser les fichiers systèmes archivés.




[BIN-84] BI : Rapports à envoyer par email aux partenaires de tracking (CDE) Création: 09/mai/06 18:46  Mise à jour: 14/sept./07 17:00  Résolue: 15/mai/06 17:51

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 4 heures
Temps consacré: Non spécifié
Estimation originale: 4 heures


 Description   
cf V:\Reporting\BusinessIntelligence\Lot 1\Specs\DSD\DSD_Marketing_partnership_11.doc

 Commentaires   
Commentaire de Samir Beghdadi [ 10/mai/06 15:53 ]
Les rapports Appel à facture sur CA et Appel à facture sur volume d'affaires sont prêts pour la validation




[cob La Redoute] Metatache (APP-13755)

[APP-14167] [Cobrand] La REdoute Occasion : Rapport BI au partenaire Création: 12/déc./06 10:09  Mise à jour: 25/juin/07 18:47  Résolue: 02/janv./07 12:48

Etat: Fermé
Projet: Application PriceMinister
Composants: Cobrandings
Affecte la/les version(s): 11.1.0 (La Redoute)
Version(s) corrigée(s): 11.1.0 (La Redoute)

Type: Sub-bug Priorité: Mineur
Rapporteur: Ghislain Gridel Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Duplicate
doublon de BIN-194 [Co-brandings] : Nouvelles rémunérations Fermé
Pays:
FRA - France
Projets PM archivés: COB La Redoute

 Commentaires   
Commentaire de Ghislain Gridel [ 12/déc./06 10:10 ]
Aathe,

Pour Redoute, : Il faut un rapport "envoi partenaire".

il est à envoyer à : dbenbass@redoute.fr

Merci.

Ghislain
Commentaire de Younès Charrière [ 12/déc./06 10:36 ]
C'est pour toi agathe :)




[Cobrand Dauphiné Libéré] (APP-15119)

[APP-15864] [Co brand Dauphiné] Activer les rapports BI Création: 10/avr./07 15:30  Mise à jour: 25/juin/07 18:51  Echéance: 13/avr./07 00:00  Résolue: 11/avr./07 14:58

Etat: Fermé
Projet: Application PriceMinister
Composants: Cobrandings
Affecte la/les version(s): 14.0.0
Version(s) corrigée(s): 14.0.0

Type: Sub-bug Priorité: Majeur
Rapporteur: Ghislain Gridel Attribution: Thomas Séglard
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM archivés: COB Dauphiné Libéré

 Commentaires   
Commentaire de Ghislain Gridel [ 10/avr./07 16:01 ]
Bonjour,

le site http://www.ledauphine-bonnesaffaires.com/ est en ligne.

Pouvez-vous activer les rapports dès dimanche prochain (15 avril) svp ?

Destinataire : Fabrice.Canet@ledl.com et patrick.claret@ledl.com

Merci
Commentaire de Agathe Remy [ 10/avr./07 19:23 ]
Ghislain, peux-tu préciser le reporting à activer :
old school ou type LRO?

Merci:-)
Commentaire de Ghislain Gridel [ 11/avr./07 12:00 ]
type LRO merci
Commentaire de Thomas Séglard [ 11/avr./07 14:58 ]
Ok. Rapport programmé toutes les semaines, au format PDF.
@+

ThomaS
Commentaire de Ghislain Gridel [ 11/avr./07 15:28 ]
Impec. Merci.




[APP-16480] BI : Ajouter une change_date sur la table USR_COUPON Création: 24/mai/07 18:32  Mise à jour: 20/nov./07 11:27  Résolue: 26/sept./07 10:49

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 18.0.0

Type: Amélioration Priorité: Critique
Rapporteur: Agathe Remy Attribution: Renaud Dierickx
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
ALL - Tous
Classif1: DB
Classif2: coupon
Projets PM archivés: Maintenance 18.x.x

 Description   
Bonjour,

Nous venons de mettre en place des rapports sur l'utilisation des coupons, hors il n'y a pas de CHANGE_DATE sur la table USR_COUPON permettant de suivre les évolutions (par exemple de statut) de cette table.
Comme elle contient plus d'1 millions de lignes, cela nous arrangerait de pouvoir l'alimenter incrémentalement et non de la recharger entièrement toutes les nuits.

Merci:-)

Agathe

 Commentaires   
Commentaire de Renaud Dierickx [ 26/sept./07 10:45 ]
C'est fait...
Pour voir cette date de modification, il faut aller sur l'écran coupon d'un utilisateur et pointer le curseur sur la date de création d'un coupon....
Voir screenshot-1




[Cobrand Nice Matin] (APP-15110)

[APP-15868] [Cob Nice Matin] Activer les rapports BI Création: 10/avr./07 16:02  Mise à jour: 25/juin/07 18:51  Echéance: 13/avr./07 00:00  Résolue: 11/avr./07 14:58

Etat: Fermé
Projet: Application PriceMinister
Composants: Cobrandings
Affecte la/les version(s): 14.0.0
Version(s) corrigée(s): 14.0.0

Type: Sub-bug Priorité: Majeur
Rapporteur: Ghislain Gridel Attribution: Thomas Séglard
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM archivés: COB Nice Matin

 Commentaires   
Commentaire de Ghislain Gridel [ 10/avr./07 16:03 ]
Bonjour,

le site http://nicematin.priceminister.com/ est en ligne.

Pouvez-vous activer les rapports dès dimanche (15 arvil), svp ?

Destinataire : ftouraille@nicematin.fr

Merci.

Ghislain
Commentaire de Agathe Remy [ 10/avr./07 19:23 ]
Ghislain, peux-tu préciser le reporting à activer :
old school ou type LRO?

Merci:-)
Commentaire de Ghislain Gridel [ 11/avr./07 12:01 ]
type LRO . Merci
Commentaire de Thomas Séglard [ 11/avr./07 14:58 ]
Ok. Rapport programmé toutes les semaines de type LRO et au format PDF.
@+

ThomaS
Commentaire de Ghislain Gridel [ 11/avr./07 16:45 ]
Impec. Merci.




[APP-14753] BI : besoin d'ajouter une CHANGE_DATE sur USR_ADDRESS Création: 23/janv./07 11:38  Mise à jour: 25/juin/07 18:48  Résolue: 20/avr./07 15:55

Etat: Fermé
Projet: Application PriceMinister
Composants: Base de données, Compte utilisateur
Affecte la/les version(s): 11.3.1
Version(s) corrigée(s): 14.0.0

Type: Amélioration Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Classif1: DB
Projets PM archivés: Maintenance 14.x.x

 Description   
Bonjour,

Je viens de me rendre compte que l'on pouvais modifier une adresse en Front ou en BackOffice.
Or il n'existe aucun moyen de tracer ces modifications (pas de change date, ni d'évènement associé à cette action).
Pour alimenter le DataWareHouse, je charge les données de manière incrémentale, à savoir j'insère les nouveaux enregistrements et je mets à jour ceux qui ont été modifiés en me basant sur la CHANGE_DATE. Or celle-ci n'existant pas sur USR_ADDRESS, je n'ai aucun moyen de savoir qu'un enregistrement a été modifié dans la base du site. Je ne peux donc pas assurer la cohérence des adresses du DataWareHouse avec celles du site.
Serait-il possible d'ajouter une CHANGE_DATE sur USR_ADDRESS afin que je puisse récupérer ces modifications?

Merci:-)

Agathe

 Commentaires   
Commentaire de Olivier Bourgeois [ 15/févr./07 15:09 ]
Ok, colonne ajoutée, script associé :

V14_0_0_APP-14753_BI_ALL_add_change_date_to_usraddress.sql

Commentaire de Agathe Remy [ 18/avr./07 17:24 ]
Le CHANGE_DATE n'est pas en NOT NULL comme sur les autres tables. Est-ce normal?
De plus, il n'a pas été inititlaisé...

Merci:-)

Agathe
Commentaire de Olivier Bourgeois [ 18/avr./07 18:24 ]
Ok j'ai relivré un script pour mettre à jour la colonne et passé la colonne not null
Commentaire de Quentin de Chivré [ 18/avr./07 18:31 ]
il faut 2 script, 1 pre deploy, et un post depoly, sinon tout va planter en prod !!!
Commentaire de Olivier Bourgeois [ 18/avr./07 18:55 ]
Oui je voulais dire : j'ai livré un script supplémentaire pour l'init (et non pas relivré le même avec l'init et le passage "not null" ajouté dedans).
Commentaire de Younès Charrière [ 20/avr./07 15:01 ]
Peux tu passer les scripts stp Patrick ?
Merci.
Commentaire de Patrick Pereira [ 20/avr./07 15:48 ]
C'est fait en Integ
Commentaire de Agathe Remy [ 20/avr./07 15:55 ]
C'est OK pour moi.

Agathe




[APP-11940] [Pangora] Afficher le nom du marchand par le biais d'un infolien Création: 31/août/06 17:26  Mise à jour: 24/oct./07 12:21  Résolue: 05/sept./07 15:11

Etat: Fermé
Projet: Application PriceMinister
Composants: Promo
Affecte la/les version(s): 9.0.3
Version(s) corrigée(s): 17.0.0

Type: Amélioration Priorité: Majeur
Rapporteur: Charles Decaux Attribution: Dispatcher (Dev-Réserve)
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Site: Prod
Projets PM: *** STANDBY ***
Classif1: PROMO
Classif2: PROMO - Pangora - monétisation

 Description   
Pour répondre aux demandes de la DGCCRF, il faut mettre un infolien au moment où l'internaute passe sa souris sur le texte de l'offre proposée par Pangora. Il ne faut pas le mettre quand l'internaute passe sa souris sur l'image.

Le texte à mettre est le suivant : "Voir l'offre de [Nom du Marchand]"

Désolé je poste ce JIRA directement vers application car mon interlocuteur fonctionnel est en congés (BLY).

Merci



 Commentaires   
Commentaire de Olivier Bourgeois [ 01/sept./06 12:40 ]
Jérôme tu pourras me donner un mini-maquettage pour ça stp ?

Il s'agit de trouver la bonne police (taille et fonderie), ainsi que les bonnes couleurs.

J'imagine qu'il doit aussi y avoir des obligations légales sur la taille de la police - non Charles on ne pourra pas mettre le texte en taille 2 pixels blanc sur fond jaune :-)
Commentaire de Charles Decaux [ 01/sept./06 15:29 ]
héhé :-)

C'est sûr qu'il faut éviter de faire un infobulle avec une police énorme .
Ma reco est donc de faire plutôt discret : l'infobulle ne sert qu'à répondre aux demandes de la DGCRRF. Mais nous on ne souhaite pas mettre en avant le nom du marchand.
Commentaire de Olivier Bourgeois [ 01/sept./06 15:52 ]
En fait on a deux choix pour l'implémentation :

- la version spartiate qui utilise l'attribut TITLE d'un lien ou d'un SPAN :

http://www.ccim.be/ccim328/trucs/info01.htm

Elle s'affiche avec un petit délai et est gerée par le navigateur à tous les niveaux (aucun contrôle de son aspect). Super simple à mettre en place.

- la version Javascriptée paramétrable au niveau du rendu :

http://www.ccim.be/ccim328/trucs/info06.html

Mais qu'il va falloir adapter un poil pour FF
Commentaire de Charles Decaux [ 07/sept./06 12:01 ]
Il me manque une validation pour effectivement ajouter l'infobulle.

Donc mise en standby

merci
Commentaire de Olivier Bourgeois [ 07/sept./06 14:13 ]
Ok pour le stand-by, je le déplace vers la 904 pour nettoyer la 903 de ses bugs
Commentaire de Olivier Bourgeois [ 29/sept./06 15:56 ]
Toujours en stand-by : procrastiné en V905
Commentaire de Charles Decaux [ 16/août/07 14:58 ]
on peut fermer cette demande




[APP-20132] BI : CHANGE_DATE antérieure à la CREATION_DATE Création: 04/avr./08 20:00  Mise à jour: 07/avr./08 15:24

Etat: Ouvert
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 19.3.2
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Arnaud Forgues
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***
Classif1: BO
Classif2: messagerie

 Description   
Bonjour,

Un enregistrement de la table USR_MESSAGE n'a pas été inséré aujourd'hui dans le DataWareHouse parce qu'il possède une CHANGE_DATE inférieure à sa CREATION_DATE.
Voici son identifiant : 122522223 (c'est un bilan vendeur).
Ce qui est vraiment étrange, c'est que cet enregistrement n'a pas été inséré dans l'alimentation du 04/04 alors que sa date de création est du 03/04?!

Serait-il possible de savoir comment ces dates sont affectées?

Merci.

Agathe


 Commentaires   
Commentaire de Julien Girardet [ 07/avr./08 15:24 ]
Bonjour,

Pour information, deux nouveaux enregistrements de la table USR_MESSAGE n'ont pas été inséré aujourd'hui et samedi dans le DataWareHouse avec une CHANGE_DATE inférieure à la CREATION_DATE.
Voici leurs identifiants : 122720546, 123082556


Julien.




[EXP-2107] pourrait on avoir des stat webalizer pour bi.priceminister.com dans l'extranet JMH ? Création: 23/mai/06 11:15  Mise à jour: 08/août/07 19:42  Résolue: 08/août/07 19:42

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Justin Ziegler Attribution: Patrice Boulanger
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Commentaires   
Commentaire de Sébastien Tournay [ 23/mai/06 16:21 ]
Je viens de faire la demande de MAI à Jet
Commentaire de Justin Ziegler [ 08/août/07 19:42 ]
on ferme !




[EXP-2871] BI : impossible de se connecter à tellus via l'utilitaire de déploiement BusinessObjects Création: 20/oct./06 16:30  Mise à jour: 25/juin/07 18:59  Résolue: 30/oct./06 15:27

Etat: Résolu
Projet: Exploitation
Composants: Troubleshooting
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Bloquant
Rapporteur: Agathe Remy Attribution: Patrice Boulanger
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Patrice,

Malgré le redémarrage de BusinessObjects hier soir, nous n'arrivons toujours plus à nous connecter à tellus via l'utilitaire de déploiement BusinessObjects.
Cette connection se fait normalement via l'arkoon sur les ports 6400 et 6402.

Nous ne pouvons donc plus passer aucune correction ou évolution en Production!!!
Il est donc urgent de régler ce problème:-)

Cela fonctionnait jusqu'au 18 otcobre 2006 inclus.

Merci:-)

Agathe



 Commentaires   
Commentaire de Patrice Boulanger [ 20/oct./06 16:59 ]
MAI-017379 ouverte chez JET pour vérifier les accès Arkoon.
Commentaire de Patrice Boulanger [ 27/oct./06 09:56 ]
Les flux ont été ouverts dans les deux sens. Merci de vérifier.
Commentaire de Patrice Boulanger [ 30/oct./06 15:27 ]
C'est résolu, je clos.




[BIN-129] BI : ajout et alimentation du champ REGISTRATION_DATE dans TD_USER_ACCOUNT Création: 17/août/06 15:12  Mise à jour: 14/sept./07 17:18  Résolue: 04/sept./06 12:01

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 2 jours
Temps consacré: Non spécifié
Estimation originale: 2 jours


 Description   
Bonjour,

Il s'agit d'ajouter un champ dans notre table TD_USER_ACCOUNT du DataMart : REGISTRATION_DATE
- Faire un document de spécification
- Mettre à jour la structure de la table dans PowerDesigner, puis dans la base de données.
Il faut ensuite alimenter ce champ via OWB :
-mettre en place l'initialisation de la table USR_EVENT dans ODS (créer la table dans ODS et développer le mapping FULL)
-développer la mise à jour journalière de la table USR_EVENT dans ODS (developper le mapping DAILY)
-développer l'alimentation de la colonne REGISTRATION_DATE dans TD_USER_ACCOUNT (développer les mappings FULL et DAILY) en fonction des règles de gestion définies précédemment dans les spécifications.

Merci:-)

Agathe


 Commentaires   
Commentaire de Agathe Remy [ 17/août/06 15:14 ]
Voici le bilan d'une première étude menée par Cyrille:

Analyse des événements de la table usr_event pour l'insertion de la date d'inscription réelle des utilisateurs.

Les événements normaux :
80 : Création de compte via achat
90 : Création de compte via annonce
100 : Création de compte standard
220 : Mutation en utilisateur

Requête ;
select trunc (min(creation_date))
from usr_event
where use_type_code in (80, 90,100,220)
group by user_account_id

Faire un min ou un max car certains utilisateurs peuvent avoir plusieurs de ces événements (exemple 100 et 220 : user_id 10844344)

Mutations :

Pour les personnes changeant de type d'utilisateur, il existe deux événements associés :
400 : Mutation en particulier
410 : Mutation en pro
 
Question : Quelle date d'inscription devons-nous prendre, ça première date d'inscription ou ça date de mutation ?

Cas particulier.
Il existe un événement dont le code est 470, libellé « Jeu ET VOUS ».

Certain des utilisateur sont considéré comme des particuliers alors qu'il ne sont pas passer par les statuts standard (voir début du mail), mais ils ont une notation dans le champ description : « inscrit ». Exemple : 2435472.
Or certain ont le code 470 avec la notion inscrit + les codes de base exemple : 1496765

Question : Quelle date devons-nous récupérer ?

Les contacts :
Aucune date d'inscription ne sera récupérée pour les contacts.

Cyrille
Commentaire de François Le Lay [ 04/sept./06 11:15 ]
Modifié mappings full et daily sur ODS pour alimentation de la table USR_EVENT. A présent on ne conserve plus que les événements de type 80,90,100,220,400 et 410. On passe ainsi de 118 millions de lignes à un peu moins de 3 millions de lignes pour le full.
Commentaire de François Le Lay [ 04/sept./06 11:56 ]
Alimentation Full de USR_EVENT sur ODS et update FULL via PL/SQL du champ REGISTRATION_DATE sur TD_USER_ACCOUNT achevés.
On a donc 2852898 utilisateurs dont la date de registration est non nulle.
Commentaire de François Le Lay [ 04/sept./06 12:01 ]
Les workflows Daily étant actifs et valides je considère la mise en place de ce champ achevée. Le package PL/SQL ayant servi à l'alimentation FULL du champ sur DTM est DTM.F_REG_DATE_USER_ACCOUNT




[BIN-241] [BI] : def des rubriques sellers count et new sellers count Création: 08/déc./06 12:11  Mise à jour: 14/sept./07 17:33  Résolue: 16/mai/07 18:34

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Alexandra Viravaud Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut Mohamed,

Dans le rapport incitation vente, que représentent les colonnes "Sellers count" et "New sellers count".
S'agit-il dans le 1er cas des personnes qui ont un inventaire ou de celles qui ont fait au moins une 1ère vente effective ?
Merci
alex


 Commentaires   
Commentaire de Agathe Remy [ 14/mai/07 11:01 ]
Samir,

Peux-tu répondre à Alex?

Merci:-)

Agathe
Commentaire de Samir Beghdadi [ 14/mai/07 15:14 ]
Salut, Alex

Pour commencer malheureusement pour toi Mohamed ne peux pas t'aider pour les Indicateurs par contre pour un séjour au Maroc je pense qu'il peut faire quelque chose.

Alors, dans le rapport "incitation vente" on a :
Le "Sellers count" : c'est le nombre des users qui ont déposés au moins une annonce jusqu'à maintenant.
Le "New sellers" : c'est le nombre des users qui ont déposés leurs première annonce dans la période choisie dans le rapport (la réponse à la question "select advert creation year")




[EXP-3550] BI : incident dans la génération des flux MM entre 3h et 7h le 30/04/2007 Création: 02/mai/07 16:54  Mise à jour: 06/août/07 15:18  Résolue: 06/août/07 15:18

Etat: Résolu
Projet: Exploitation
Composants: Troubleshooting
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Patrice Boulanger
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Le traitement journalier de génération des flux 1000Mercis a duré 3h au lieu de 10mn?! Depuis, c'est revenu à la normale...

En investiguant, nous nous sommes aperçus que c'étaient les scripts d'initialisation (init_file.sh) et de finalisation (finalize.sh) des fichiers qui duraient en moyenne 300 secondes pour juste ouvrir une fifo et écrire une ligne?!!!
Pouvez-vous trouver ce qui s'est passé?

Vous trouverez les scripts exécutés dans les répertoire /home/oracle/owb_outgoing de latone.

Merci:-)

Agathe

 Commentaires   
Commentaire de Justin Ziegler [ 06/août/07 14:36 ]
Agathe, peut on fermer ce jira ?
Est ce que le pb est résolu ?
Commentaire de Agathe Remy [ 06/août/07 15:18 ]
En effet, cet incident a été réglé : je ne me souviens plus très bien du pourquoi et du comment, mais c'était une histoire de saturation de disque en écriture...

Agathe




[BIN-387] [Vehicle/Affiliation] : données pas à jour sur les rapport BI Affiliation Auto Création: 05/nov./07 11:53  Mise à jour: 16/nov./07 14:38  Résolue: 09/nov./07 16:13

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Lorenzo Nuccio Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello,

comme vu ensemble.
le dernier rapport que j'ai sorti sur les dépots d'annonce auto identifie des annonces déposées comme "non valide". Il faudrait donc voir d'où vient le problème pour pouvoir générer le rapport avec des données à jour.

Merci

 Commentaires   
Commentaire de Romain Czornomaz [ 09/nov./07 16:13 ]
Lorenzo,

Il y avait un bug dans la mise à jour de la date de publication.
J'ai modifié l'alimentation des données d'annonces auto et refait une initialisation des données. Vérifie sur ton rapport d'affiliation si les chiffres sont de nouveau corrects afin que je puisse fermer la demande.

Bonne journée,

Romain
Commentaire de Romain Czornomaz [ 16/nov./07 14:38 ]
Lorenzo,

Je ferme la demande suite à ta validation.

Romain




[BIN-512] [Droits d'accès BI] : demande d'accès aux rapports Wish pour l'utilisateur UR Technique Création: 06/nov./08 17:10  Mise à jour: 24/nov./08 16:22  Résolue: 06/nov./08 18:42

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Emeric Teil Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Pourriez-vous ouvrir le répertoire "Wish" à l'utilisateur "UR Technique" ?

 Commentaires   
Commentaire de Agathe Remy [ 06/nov./08 18:17 ]
A toi de jouer!

Merci:-)
Commentaire de Julien Girardet [ 06/nov./08 18:42 ]
Emeric,

Le repertoire Wish est dispo avec le user UR Technique
Amuse toi bien ;)

Julien.




[BIN-156] BI : prise en compte de l'évoluation de USR_SUBSCRIPTION avec la V9.0.3 Création: 19/sept./06 14:56  Mise à jour: 14/sept./07 17:20  Résolue: 10/oct./06 18:37

Etat: Fermé
Projet: Business Intelligence
Composants: Bug & Improvement
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 1 jour
Temps consacré: Non spécifié
Estimation originale: 1 jour

Pays:
FRA - France

 Description   
Modification de l'alimentation du Datawarehouse et prise en compte des nouvelles données dans l'univers




[BIN-341] ouvrir les droits d'accès du rapport BI nb propects 2 (OM) Création: 06/juin/07 11:59  Mise à jour: 14/sept./07 18:04  Résolue: 11/juin/07 11:03

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Alexandra Viravaud Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut,

dans le cadre du calcul de l'incentive MM, j'ai besoin de connaitre chaque mois le nb de comptes hors viral.
Il me faut pour cela utiliser le rapport d'Olivier "nb prospects 2". Pour le moment, je peux accéder à ce rapport mais je ne peux pas le faire tourner en choissant la période qui m'intéresse pour les données.
Pouvez-vous élargir les droits sur ce rapport ?
Merci
Alexandra

 Commentaires   
Commentaire de Samir Beghdadi [ 11/juin/07 11:03 ]
D'aprés Alexandra c'est réglé.

Merci




[EXP-1573] BI : problème de connexion à http://latone.lan:5500/em/ Création: 21/mars/06 10:39  Mise à jour: 25/juin/07 18:57  Résolue: 22/mars/06 16:49

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Agathe Remy Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 35 minutes
Estimation originale: Non spécifié


 Description   
Bonjour,

Il nous est impossible de se connecter ce matin à l'adresse suivante :
http://latone.lan:5500/em/

Y aurait-il un problème avec l'Arkoon?

Merci:-)

Agathe

 Commentaires   
Commentaire de Sébastien Tournay [ 21/mars/06 16:27 ]
On avait effectivement un problème au niveau du FortiGate. On avait constaté cela sur d'autres URL. Jérémie, tu peux nous confirmer que c'est rentré dans l'ordre.

Je voudrais également comprendre l'origine du problème. Il semblerait que cela soit lié à la modification d'une régle. Qui, quoi, comment ?
Commentaire de Jérémie Bennejean [ 21/mars/06 18:10 ]
Depuis la fin de matinée l'accès à http://latone.lan:5500/em/ est possible. Cela est donc rentré dans l'ordre.

L'origine du problème viens effectivement de la modification d'un paramétre d'une nos règles.

La règle en question concerne wan2 qui dit que tout ce qui est en provenance du réseau 192.168.1.0/24 ( via internal) et qui en direction de wan2 est authorisé. ( sur un le plan on comprends mieux)
L'option NAT doit être décocher ( sinon passage en @ de type 192.168.2.X, ce qui a été le cas ... ) et donc le routeur 9 tel n'acceptais pas les connections sur cette plage d'adresse.

Maintenant reste à déterminer qui à modifier cette règle.
Une premiere recherche dans les logs n'a rien retourné. Par ailleurs il n'y a pas de logs spécifiques aux connections sur le fortigate ( même en mode administration) ... ce qui rend les recherches totalement floues.





[BIN-535] [CRM achat] : création de filtres sous BI dans les univers USER ACCOUNT et PURCHASE Création: 02/janv./09 14:40  Mise à jour: 18/nov./10 18:07

Etat: Ouvert
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Thomas Beylot Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello

comme vu avec Dalila, j'aimerais créer un nouveau filtre dans l'univers user account qui me permettrait de sortir le nombre de nouveaux clients qui auraient fait leur premier achat dans les 45 jours suivant leur inscription en sélectionnant un pool de nouveaux clients par leur date d'arrivée dans la base.
En effet ça me permettra d'affiner les projections budgétaires faite sur la campagne "Inscrits non acheteurs" mais aussi de voir si les diverses actions entreprises permettent d'augmenter le taux de transfo des inscrits non acheteurs.

De plus je souhaiterais créer (ou alors il existe mais je ne l'ai pas trouvé) une autre dimension sur l'univers Item. En effet je souhaiterais pouvoir disposer de la note attribué à un produit par l'acheteur suite à son acte d'achat sur PM. Aujourd'hui j'ai l'impression que cette data n'est disponible que sous la forme d'une note attribué à un vendeur (en somme et en moyenne) ?

à votre dispo pour plus de précisions,

thomas

 Commentaires   
Commentaire de Dalila Belkebir [ 02/janv./09 18:14 ]
Bonjour Thomas,

La dimension " Item seller score " existe déjà dans l'univers ITEM. Tu la trouveras dans la classe ITEM (32 ème dimension) puisque une note est attribuée sur chaque item d'un panier.

Pour ton autre demande, peux-tu nous dire si ton besoin est ponctuel (j'ai oublié de te le demander)?
Si c'est le cas je te propose de te faire une extraction comme pour les autres études MKT.
Sinon, nous regarderons quel est le meilleur filtre à créer.

Cordialement,
Dalila.
Commentaire de Thomas Beylot [ 05/févr./09 10:20 ]
hello

je regarde le coup du "item seller score" asap.

pour mon autre demande elle est n'est pas ponctuelle non. Il s'agit de vérifier de façon régulière l'évolution du nb d'acheteurs / inscrits 45j car on a mis en place des mails auto pour améliorer cette transfo (par exemple).


thomas




[BIN-688] [Jeu vendeur] Intégrer à BI la donnée d'inscription d'un PriceMember au jeu vendeur Création: 03/sept./10 11:07  Mise à jour: 21/déc./10 10:21  Résolue: 20/déc./10 16:15

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Fabrice Feugas Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Commentaires   
Commentaire de Fabrice Feugas [ 03/sept./10 11:08 ]
Le lien vers le wiki (en cours de construction) : http://pricewiki.lan/Wiki.jsp?page=Jeu%20vendeur
Commentaire de Fabrice Feugas [ 26/oct./10 14:46 ]
URL obsolète, voici la nouvelle : http://pricewiki.lan/Wiki.jsp?page=JeuVendeur2010
Commentaire de Julien Girardet [ 20/déc./10 16:15 ]
Livré le 09/12/10 :

=> Univers USER ACCOUNT (classe Seller), ITEM (classe Seller account), ADVERT (classe User Account) :
- Is seller game player ? : booléen indiquant si le PriceMember est inscrit au jeu vendeur
- Seller game subscription date : date d'inscription au jeu vendeur
- Seller game subscription month : mois d'inscription au jeu vendeur
- Seller game player : filtre sélectionnant les PriceMembers inscrit au jeu vendeur
- Select seller game subscription date : filtre pour sélectionner une date d'inscription au jeu vendeur
- Select seller game subscription date period : filtre pour sélectionner une période de date d'inscription au jeu vendeur
- Select seller game subscription month : filtre pour sélectionner un mois d'inscription au jeu vendeur
- Select seller game subscription month period : filtre pour sélectionner une période de mois d'inscription au jeu vendeur

Je ferme donc le JIRA.
Commentaire de Fabrice Feugas [ 21/déc./10 10:21 ]
Merci.




[APP-15803] BI : Ajout des champs CREATION_DATE et CHANGE_DATE sur PRD_ATTRIBUTE Création: 03/avr./07 18:41  Mise à jour: 02/août/07 11:43  Résolue: 01/août/07 15:55

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 13.2.2
Version(s) corrigée(s): 16.0.0

Type: Nouvelle fonctionnalité Priorité: Critique
Rapporteur: Agathe Remy Attribution: Mostafa Diane
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Classif1: TECH
Projets PM archivés: Maintenance 16.x.x

 Description   
Bonjour,

Afin de pouvoir mettre en place le reporting Voiture, nous avons besoin de récupérer en incrémental des attributs.
Pour éviter de surcharger la base OLTP, pouvez-vous créer les champs CREATION_DATE et CHANGE_DATE sur PRD_ATTRIBUTE avec les indexs adéquats?

Merci:-)

Agathe

 Commentaires   
Commentaire de Nicolas Chauveau [ 04/mai/07 10:47 ]
Le change date est il impacté par
- a modif du lien produit / attribut
- la modification de la valeur de l'attribut
Commentaire de Martin Sudmann [ 15/juin/07 09:53 ]
1/
OK pour maintenir les dates sur changement de la table prd_attribute, NOK pour répercuter les changements de prd_attribute_value sur prd_attribute (mais après discussion avec Agathe, ce n'est pas nécessaire)

2/
Agathe, peux-tu mettre ta requête dans ce jira pour voir quel index il te faut ?
Commentaire de Agathe Remy [ 15/juin/07 10:41 ]
Voici la requête :
SELECT *
FROM PRD_ATTRIBUTE
WHERE CHANGE_DATE>=TRUNC(sysdate-1)
AND INOUTGRP1.CREATION_DATE<TRUNC(sysdate)
;

Cordialement,
Agathe
Commentaire de Martin Sudmann [ 15/juin/07 15:04 ]
le remplissage des dates dans les attributs étant trop lourd pour la V15 (SBP !), décalage en V16
Commentaire de Martin Sudmann [ 11/juil./07 14:24 ]
à traiter ensemble avec VID
Commentaire de Mostafa Diane [ 17/juil./07 11:06 ]
Désormais les deux colonnes existent et sont gérés par l'appli. J'ai également crée deux indexes sur les deux colonnes
Commentaire de Manuel Sadok [ 01/août/07 14:30 ]
Problème de trigger lors d'une mise à jour d'attribut en BO

2007-08-01 14:18:34,501 INFO [P-Processor8] :velocitycoupon - >>> POST http://bo.pm.lan/referential_back!action=attributeu...&namekey=PMA0001501&prdattributeid=1260926113&productid=53362865&valuekey=PMK0000215&x=33&y=16
...
2007-08-01 14:18:34,534 WARN [P-Processor8] :velocitycoupon - SQL Error: 4098, SQLState: S1000
2007-08-01 14:18:34,534 ERROR [P-Processor8] :velocitycoupon - [Oracle] #17 ORA-04098: trigger 'PRODUCT_1.TRG_SORT_ATTRIBUTE2' is invalid and failed re-validation

2007-08-01 14:18:34,534 ERROR [P-Processor8] :velocitycoupon - Could not synchronize database state with session
org.hibernate.exception.GenericJDBCException: could not insert: [com.babelstore.stock.entity.PrdAttribute]
        at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:91)
        at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:79)
        at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
        at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2077)
        at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2426)
        at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:51)
        at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
        at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296)
        at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
        at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:877)
        at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:201)
        at org.jboss.ejb3.entity.InjectedEntityManager.flush(InjectedEntityManager.java:122)
        at com.babelstore.stock.service.ProductManagerBean.flush(ProductManagerBean.java:1066)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:109)
        at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:32)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:113)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:138)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:32)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
 
Commentaire de Mostafa Diane [ 01/août/07 15:55 ]
le trigger TRG_SORT_ATTRIBUTE2 a été droppé par Patrick. refait les tests :)




[APP-19155] BI : suppression d'une annonce de recrutement sur le site www.PriceMinister.com Création: 14/janv./08 14:45  Mise à jour: 21/janv./08 17:13  Résolue: 18/janv./08 16:41

Etat: Fermé
Projet: Application PriceMinister
Composants: Aide en ligne, Infoglue
Affecte la/les version(s): 18.1.3
Version(s) corrigée(s): 18.1.3

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Steven Harel
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: *** A PLANIFIER ***

 Description   
Bonjour,

Serait-il possible de supprimer l'annonce de recrutement suivante :
Stagiaire alternance ciblage Emailing

Merci:-)

Agathe

 Commentaires   
Commentaire de Steven Harel [ 17/janv./08 08:41 ]
inactivé dans infoglue
Commentaire de Christophe Garcia [ 18/janv./08 14:40 ]
Ariane, c'est parti en PROD ce truc ?
Commentaire de Ariane Baldinger [ 18/janv./08 14:56 ]
Non.
Je fais l'export / import aujourd'hui pour mise en Prod début semaine prochaine.




[APP-7691] BI : problème d'affectation de la valeur de creation_date dans USR_COUPON pour les coupons de parrainage Création: 02/mars/06 10:56  Mise à jour: 25/juin/07 18:35  Résolue: 10/mars/06 08:13

Etat: Fermé
Projet: Application PriceMinister
Composants: Coupons
Affecte la/les version(s): 8.1.2
Version(s) corrigée(s): 8.1.2

Type: Bogue Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Geneviève Beaujard
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Site: Prod

 Description   
Bonjour,

Après discussion avec Quentin, il ne semble pas pertinent que la date de création des enregistrements des coupons CORLEONE soit affectée à la start_date. Il est donc envisageable de l'affecter avec la date de création de l'enregistrement (comme pour les autres coupons), ce qui nous permettrait d'alimenter le Datawarehouse sans recharger tous les jours la table USR_COUPON en entier.
Voici donc l'object de ce JIRA :
1- Faire une étude des impacts éventuels de cette modification (i.e. voir si cette creation_date est utilisée pour calculer autre chose...)
2- Si les risques de régression de l'application ne sont pas trop grands, effectuer cette correction pour la version 8.1.2.

Merci:-)

Je suis à ta disposition pour toute question.

Agathe

 Commentaires   
Commentaire de Geneviève Beaujard [ 02/mars/06 13:01 ]
Seule la creation des coupons dont l'assignation est CouponStrategy.ASSIGNEMENT_USER
se fait au moment de l'utilisation du coupon.

Par exemple un coupon CORLEONE est crée lors du premier achat d'un filleul ET il est tout a fait normal
que creation_date = start_date, dans ce cas la il s'agit d'une attribution.

Pour agathe il faudrait creer une autre colonne 'date d'utilisation' que l'on renseignerai lors de l'utilisation.

J'attends un feu vert pour savoir si c'est une bonne voie.
Commentaire de Geneviève Beaujard [ 03/mars/06 15:37 ]
Les coupons qui sont créés un certain jour avec une date de creation qui est inferieur a la date du jour
sont des coupons créés suite à la capture d'un panier
si le panier a expiré
ou si certains articles du panier annulés par le vendeur entrainent l'annulation du coupon.

Danc se cas le coupon utilisé est detruit (ucp_status_code = 60),
MAIS un nouveau coupon est créé avec toutes les infos de précedent coupon (dont creation_date).

Pour ta solution il faudrait faire une modification dans l'EJBGenerator pour que le methode copyCouponInfo
de UsrCouponEntityBean ne recopie pas creation_date et que ce soit bien le jboss qui mette la creation date
(balise <audit>), je cree un bug dans ce sens: http://pricejira.lan/browse/APP-7716
  extrait de advertbusiness-jbosscmp-jdbc.xml dans generated/advert
    <audit>
        <created-time>
          <field-name>creationDateValue</field-name>
        </created-time>
        <updated-time>
          <field-name>changeDateValue</field-name>
        </updated-time>
      </audit>
Commentaire de Judd OSullivan [ 08/mars/06 18:58 ]
Fabrice va mettre à jour le generater des INFO (APP-7716) mais ca serait pas près pour le 8.1.2. Donc pour le 8.1.2, Genevieve va forcer une MAJ de creation_date avec la date d'aujourdhui.
Commentaire de Geneviève Beaujard [ 09/mars/06 14:55 ]
Ok, mais il faudra nettoyer le CouponBusinessBean apres résolution du bug app-7116.
Commentaire de Patrick Condevaux [ 15/mars/06 17:18 ]
ok verifie avec genevieve




[BIN-170] BI Finance : rapports Purchase by card type et Purchase by payment type Création: 11/oct./06 12:31  Mise à jour: 14/sept./07 17:21  Résolue: 30/oct./06 18:34

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Critique
Rapporteur: Agathe Remy Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures

Pays:
FRA - France

 Description   
- Modifier l'invite par mois en une invite par jour
- vérifier le montant coupon qui est toujours égal à 0???

 Commentaires   
Commentaire de Agathe Remy [ 11/oct./06 13:07 ]
Le montant coupon a été corrigé et l'invite modifiée.

Peux-tu me valider les rapports?

Merci.

Agathe




[IMP-4736] Mise à jour des stocks > le pro est en -2 tant que les stocks ne sont pas à jour > il s'agît juste d'importer l'export BI avec les quantités > coco457 Création: 26/nov./09 14:51  Mise à jour: 01/déc./09 10:43  Résolue: 01/déc./09 10:43

Etat: Résolu
Projet: Paramétrage - Import
Composants: Support entrant
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Isabelle Weisbecker Attribution: Frédéric Nahum
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel coco457_Advert listing by login.xls    
Pays:
FRA - France
Login: coco457
Séparateur: N/A
Type de traitement:
Mise à jour/création annonces avec mise à jour/création produits (écrasement)

 Commentaires   
Commentaire de Frédéric Nahum [ 01/déc./09 10:19 ]
j'ai soumis le fichier pour les maj de quantité
Commentaire de Frédéric Nahum [ 01/déc./09 10:43 ]
c'est fait




[BCK-24] [EP] [Tech] Refaire le nouveau cycle de vie / schéma BDD et les renvoyer aux DBA / BI Création: 18/août/10 08:05  Mise à jour: 22/sept./10 18:17  Résolue: 30/août/10 16:13

Etat: Fermé
Projet: Backlog Projets
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Renaud Dierickx Attribution: Damien Dorizy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM: Espace personnalisé

 Commentaires   
Commentaire de Damien Dorizy [ 30/août/10 15:56 ]
C'est dans le Wiki : http://pricewiki.lan/Wiki.jsp?page=Impacts%20BDD%20CTN-U#section-Impacts+BDD+CTN-U-D_C3_A9tailEspacePerso




[IMP-7780] Création format import rapport BI "Advert listing by login " + import des annonces > frenchstyle Création: 06/janv./11 12:21  Mise à jour: 19/janv./11 10:43  Résolue: 19/janv./11 10:43

Etat: Résolu
Projet: Paramétrage - Import
Composants: Demande commerciale
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Isabelle Weisbecker Attribution: Jérome Marianne
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel extraction annonces 06.01.2011.csv    
Pays:
FRA - France
Login: frenchstyle
Modèle: Advert listing by login
Séparateur: Point-virgule (;)
Type de traitement:
Mise à jour/création annonces avec mise à jour/création produits (écrasement)

 Commentaires   
Commentaire de Habib-Sylvain Gourguet [ 10/janv./11 15:19 ]
Bonjour,

Pour compléter la demande : le vendeur "frenchstyle" a vu ses annonces supprimées suite à une erreur en BO d'un opérateur SAV.

Suite à cette erreur (qui nous est imputable), le vendeur harcèle le standard, le Service commercial et le Back Office d'appels téléphoniques.

Merci de faire au mieux pour traiter en priorité cette demande.
Commentaire de Habib-Sylvain Gourguet [ 14/janv./11 16:39 ]
Re,

Peut-on avoir plus d'informations quant au délai envisagé pour traiter cette demande, svp ?

Ce vendeur PRO attend depuis maintenant près de 10 jours que PriceMinister répare son erreur, qui l'empêche de vendre sur notre site.
Commentaire de Jérome Marianne [ 18/janv./11 18:34 ]
Format et profil import paramétrés.

Fichier soumis en création annonce avec recherche par ID produit.

Commentaire de Jérome Marianne [ 19/janv./11 10:43 ]
Les annonces sont en ligne.




[IMP-7918] Le pro veut baisser ses prix en masse mais ne passe pas par les imports > passer l'extraction BI > magicprix Création: 27/janv./11 11:02  Mise à jour: 31/janv./11 15:57  Résolue: 31/janv./11 15:57

Etat: Résolu
Projet: Paramétrage - Import
Composants: Demande commerciale
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Isabelle Weisbecker Attribution: Esteban Rios
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Advert listing by login_magicprix_27.01.2011.csv    
Pays:
FRA - France
Login: magicprix
Modèle: extraction BI
Séparateur: Point-virgule (;)
Type de traitement:
Mise à jour/création annonces avec mise à jour/création produits (écrasement)

 Commentaires   
Commentaire de Esteban Rios [ 31/janv./11 12:06 ]
le fichier sera traité et MAJ annonce et pas Mise à jour/création annonces avec mise à jour/création produits (écrasement) car nous allons seulement mettre à jour les prix dans les annonces. Merci de mettre à jour le jira.
(traitement convenu avec Isabelle Weisbecker par telephone)
Commentaire de Esteban Rios [ 31/janv./11 14:55 ]
Fichier en cours de traitement :
http://bo.priceminister.com/datafile_back?action=advfilesearch&file_id=11611037&login=magicprix+&process_code=&status=&use_proc_date=false&start_date=&end_date=&order=&x=0&y=0
Commentaire de Esteban Rios [ 31/janv./11 15:47 ]
Demande traitée.





[EXP-590] Mettre en place les alertes minitord sur lanson Création: 16/déc./05 12:20  Mise à jour: 25/juin/07 18:55  Résolue: 18/janv./06 19:10

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Edouard Laurent Attribution: Xiaoming Du
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Il faudrait mettre en place des alertes minitord, ces alertes sont en rapport uniquement avec la plateforme BI (agathe)
a ta dispo pour en parler


 Commentaires   
Commentaire de Sébastien Tournay [ 19/déc./05 18:01 ]
Bien définir un profil métier type BI que nous allons mettre en place. L'idée ensuite et de pousser ce profil sur la prod au même titre que nous avons un profil APACHE, JBOSS et BDD.
Commentaire de Xiaoming Du [ 18/janv./06 19:10 ]
BI sera installé sur pommery.

http://pricejira.lan/browse/EXP-786




[IMP-2994] extraction stock alphalibris Création: 12/déc./08 11:01  Mise à jour: 30/oct./09 15:43  Résolue: 12/déc./08 15:12

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Anne Korchia Attribution: Fotigui Tangara
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: alphalibris
Séparateur: Tabulation
Type de traitement:
Mise à jour/création annonces avec création produits (écrasement)

 Description   
je n'arrive pas à extraire le stock d' alphalibris sur bi pourriez vous le faire pour moi car il faut que je fasse la mise à jour de son stock

 Commentaires   
Commentaire de Fotigui Tangara [ 12/déc./08 15:12 ]
Nous ne disposons plus d'outils pour l'extraction de stock. Pour cela adressez-vous à l'équipe BI (Agathe).




"Erreur - non disponible" dans les "Problèmes Q&A Produits" (APP-29492)

[APP-29495] Création d'un script de correction des données Création: 07/mai/10 17:52  Mise à jour: 12/mai/10 11:26  Résolue: 07/mai/10 18:00

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 68.0.2

Type: Sub-bug Priorité: Mineur
Rapporteur: Renaud Dierickx Attribution: Ayoub Benseghir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM: *** RESERVE ***

 Description   
Le script a été créé en dev.

Il faut le lancer en integ :
V:\Database\V68_0_2\integ

!!!!!!!!!!!! Attention, en prod il faudra garder les logs pour le BI !!!!!!!!!!!!

 Commentaires   
Commentaire de Ayoub Benseghir [ 10/mai/10 11:01 ]
1 seule ligne en integ france:
Update entity_post_relation_id n°44011 set entity_id = 92219457

rien en ES/UK.

J'envoi en PROD?
Commentaire de Cédric Goldovsky [ 10/mai/10 11:16 ]
en prod 40 questions concernées en 24H la semaine dernière
Cela signifie qu'en théorie, on doit en avoir 160 concernées à cette heure.

Tu peux le passer en PROD pour régler le problème mais n'oublie pas qu'il faudra le repasser en POST DEPLOY afin de corriger le delta.

enfin, après passage en prod, pourras tu coller ici tous les updates réalisés (pour le BI)

Merci
Commentaire de Renaud Dierickx [ 11/mai/10 15:49 ]
Les logs de prod :

11/05/2010-09:42
--------------------------------------------------------------------
Execution du script V68_0_2_APP-29492_ALL_correction_des_entity_post_relation.sql sur la base GLOB
--------------------------------------------------------------------
 
=== Start 11/05/2010 09:42:54 ========
 
Connecté.
Update entity_post_relation_id n°87511 set entity_id = 76014366
Update entity_post_relation_id n°87518 set entity_id = 50837583
Update entity_post_relation_id n°87487 set entity_id = 75933832
Update entity_post_relation_id n°87500 set entity_id = 81422259
Update entity_post_relation_id n°87554 set entity_id = 50022497
Update entity_post_relation_id n°87556 set entity_id = 97133816
Update entity_post_relation_id n°87559 set entity_id = 69679642
Update entity_post_relation_id n°87526 set entity_id = 53409377
Update entity_post_relation_id n°87535 set entity_id = 92617167
Update entity_post_relation_id n°87537 set entity_id = 16800345
Update entity_post_relation_id n°87539 set entity_id = 98903267
Update entity_post_relation_id n°87653 set entity_id = 52413378
Update entity_post_relation_id n°87612 set entity_id = 63393080
Update entity_post_relation_id n°87571 set entity_id = 9872781
Update entity_post_relation_id n°87573 set entity_id = 88076275
Update entity_post_relation_id n°87577 set entity_id = 57031924
Update entity_post_relation_id n°87568 set entity_id = 93227686
Update entity_post_relation_id n°87621 set entity_id = 46829509
Update entity_post_relation_id n°87623 set entity_id = 17293981
Update entity_post_relation_id n°87632 set entity_id = 84826049
Update entity_post_relation_id n°87643 set entity_id = 534522
Update entity_post_relation_id n°87586 set entity_id = 47234320
Update entity_post_relation_id n°87589 set entity_id = 5808303
Update entity_post_relation_id n°87663 set entity_id = 85611891
Update entity_post_relation_id n°87671 set entity_id = 54335497
Update entity_post_relation_id n°87676 set entity_id = 101284720
Update entity_post_relation_id n°87617 set entity_id = 58806025
Update entity_post_relation_id n°87682 set entity_id = 82285498
Update entity_post_relation_id n°87684 set entity_id = 58671788
Update entity_post_relation_id n°87686 set entity_id = 82015380
Update entity_post_relation_id n°87703 set entity_id = 2922348
Update entity_post_relation_id n°87708 set entity_id = 99346094
Update entity_post_relation_id n°87710 set entity_id = 3660139
Update entity_post_relation_id n°87680 set entity_id = 88681359
Update entity_post_relation_id n°87722 set entity_id = 57149797
Update entity_post_relation_id n°87727 set entity_id = 90621344
Update entity_post_relation_id n°87717 set entity_id = 394039
Update entity_post_relation_id n°87734 set entity_id = 57716530
Update entity_post_relation_id n°87739 set entity_id = 59311709
Update entity_post_relation_id n°87783 set entity_id = 57663448
Update entity_post_relation_id n°87891 set entity_id = 52012839
Update entity_post_relation_id n°87893 set entity_id = 7022711
Update entity_post_relation_id n°87812 set entity_id = 51866031
Update entity_post_relation_id n°87816 set entity_id = 934315
Update entity_post_relation_id n°87827 set entity_id = 85209508
Update entity_post_relation_id n°87831 set entity_id = 10976395
Update entity_post_relation_id n°87984 set entity_id = 73277696
Update entity_post_relation_id n°87955 set entity_id = 53375532
Update entity_post_relation_id n°87841 set entity_id = 92426141
Update entity_post_relation_id n°87850 set entity_id = 92076098
Update entity_post_relation_id n°87874 set entity_id = 83457058
Update entity_post_relation_id n°87881 set entity_id = 91647698
Update entity_post_relation_id n°87886 set entity_id = 58506466
Update entity_post_relation_id n°87902 set entity_id = 54897365
Update entity_post_relation_id n°87973 set entity_id = 89651854
Update entity_post_relation_id n°87913 set entity_id = 55109017
Update entity_post_relation_id n°87916 set entity_id = 586498
Update entity_post_relation_id n°87919 set entity_id = 99264738
Update entity_post_relation_id n°87947 set entity_id = 81116767
Update entity_post_relation_id n°87923 set entity_id = 17407394
Update entity_post_relation_id n°87933 set entity_id = 3778134
Update entity_post_relation_id n°87964 set entity_id = 73885572
Update entity_post_relation_id n°87966 set entity_id = 46508981
Update entity_post_relation_id n°88004 set entity_id = 60755744
Update entity_post_relation_id n°88012 set entity_id = 18581576
Update entity_post_relation_id n°88016 set entity_id = 6409638
Update entity_post_relation_id n°88051 set entity_id = 1796364
Update entity_post_relation_id n°88032 set entity_id = 53985790
Update entity_post_relation_id n°88034 set entity_id = 81877587
Update entity_post_relation_id n°87986 set entity_id = 72450133
Update entity_post_relation_id n°88008 set entity_id = 51445607
Update entity_post_relation_id n°88062 set entity_id = 143387
Update entity_post_relation_id n°87978 set entity_id = 85106066
Update entity_post_relation_id n°88071 set entity_id = 83792072
Update entity_post_relation_id n°88076 set entity_id = 91726653
Update entity_post_relation_id n°88102 set entity_id = 18053686
Update entity_post_relation_id n°88109 set entity_id = 76158835
Update entity_post_relation_id n°88112 set entity_id = 99503154
Update entity_post_relation_id n°88135 set entity_id = 53462530
Update entity_post_relation_id n°88139 set entity_id = 59062629
Update entity_post_relation_id n°88143 set entity_id = 48472894
Update entity_post_relation_id n°88145 set entity_id = 76880135
Update entity_post_relation_id n°88147 set entity_id = 81275963
Update entity_post_relation_id n°88149 set entity_id = 46551688
Update entity_post_relation_id n°88155 set entity_id = 98646599
Update entity_post_relation_id n°88159 set entity_id = 63642863
Update entity_post_relation_id n°88163 set entity_id = 70677679
Update entity_post_relation_id n°88165 set entity_id = 85100166
Update entity_post_relation_id n°88175 set entity_id = 80446378
Update entity_post_relation_id n°88177 set entity_id = 69761350
Update entity_post_relation_id n°88179 set entity_id = 69761350
Update entity_post_relation_id n°88251 set entity_id = 69761350
Update entity_post_relation_id n°88187 set entity_id = 4416503
Update entity_post_relation_id n°88191 set entity_id = 61985127
Update entity_post_relation_id n°88212 set entity_id = 17454840
Update entity_post_relation_id n°88216 set entity_id = 94262304
Update entity_post_relation_id n°88224 set entity_id = 88243675
Update entity_post_relation_id n°88241 set entity_id = 89209751
Update entity_post_relation_id n°88243 set entity_id = 98170897
Update entity_post_relation_id n°88246 set entity_id = 1199513
Update entity_post_relation_id n°88253 set entity_id = 69761350
Update entity_post_relation_id n°88255 set entity_id = 428610
Update entity_post_relation_id n°88261 set entity_id = 69761350
Update entity_post_relation_id n°88275 set entity_id = 5038732
Update entity_post_relation_id n°88283 set entity_id = 48078300
Update entity_post_relation_id n°88292 set entity_id = 2368264
Update entity_post_relation_id n°88303 set entity_id = 48670384
Update entity_post_relation_id n°88305 set entity_id = 228165
Update entity_post_relation_id n°88307 set entity_id = 323464
Update entity_post_relation_id n°88310 set entity_id = 851207
Update entity_post_relation_id n°88311 set entity_id = 98610292
Update entity_post_relation_id n°88313 set entity_id = 69365465
Update entity_post_relation_id n°88323 set entity_id = 99267616
Update entity_post_relation_id n°88337 set entity_id = 53600584
Update entity_post_relation_id n°88341 set entity_id = 48979481
Update entity_post_relation_id n°88343 set entity_id = 1089309
Update entity_post_relation_id n°88381 set entity_id = 78872082
Update entity_post_relation_id n°88391 set entity_id = 75971399
Update entity_post_relation_id n°88395 set entity_id = 99462207
Update entity_post_relation_id n°88376 set entity_id = 48534998
Update entity_post_relation_id n°88433 set entity_id = 92985061
Update entity_post_relation_id n°88553 set entity_id = 90478779
Update entity_post_relation_id n°88454 set entity_id = 1133619
Update entity_post_relation_id n°88514 set entity_id = 10518673
Update entity_post_relation_id n°88516 set entity_id = 3288433
Update entity_post_relation_id n°88473 set entity_id = 2539984
Update entity_post_relation_id n°88486 set entity_id = 3322381
Update entity_post_relation_id n°88491 set entity_id = 81057949
Update entity_post_relation_id n°88493 set entity_id = 98609798
Update entity_post_relation_id n°88500 set entity_id = 299974
Update entity_post_relation_id n°88742 set entity_id = 63403019
Update entity_post_relation_id n°88504 set entity_id = 46813090
Update entity_post_relation_id n°88459 set entity_id = 90412352
Update entity_post_relation_id n°88542 set entity_id = 1049219
Update entity_post_relation_id n°88548 set entity_id = 5270600
Update entity_post_relation_id n°88521 set entity_id = 16485617
Update entity_post_relation_id n°88524 set entity_id = 93614954
Update entity_post_relation_id n°88535 set entity_id = 99768248
Update entity_post_relation_id n°88537 set entity_id = 18538045
Update entity_post_relation_id n°88581 set entity_id = 89661850
Update entity_post_relation_id n°88593 set entity_id = 62830737
Update entity_post_relation_id n°88622 set entity_id = 2496922
Update entity_post_relation_id n°88662 set entity_id = 60691145
Update entity_post_relation_id n°88612 set entity_id = 77402243
Update entity_post_relation_id n°88618 set entity_id = 531381
Update entity_post_relation_id n°88635 set entity_id = 5353098
Update entity_post_relation_id n°88671 set entity_id = 97117812
Update entity_post_relation_id n°88674 set entity_id = 71291068
Update entity_post_relation_id n°88695 set entity_id = 68578472
Update entity_post_relation_id n°88712 set entity_id = 77534795
Update entity_post_relation_id n°88715 set entity_id = 1004211
Update entity_post_relation_id n°88718 set entity_id = 1180272
Update entity_post_relation_id n°88723 set entity_id = 3213560
Update entity_post_relation_id n°88610 set entity_id = 52792823
Update entity_post_relation_id n°88771 set entity_id = 96573975
Update entity_post_relation_id n°89023 set entity_id = 504963
Update entity_post_relation_id n°88783 set entity_id = 5865116
Update entity_post_relation_id n°88798 set entity_id = 81167912
Update entity_post_relation_id n°88803 set entity_id = 50698169
Update entity_post_relation_id n°88807 set entity_id = 101406448
Update entity_post_relation_id n°88825 set entity_id = 48810491
Update entity_post_relation_id n°88831 set entity_id = 81504546
Update entity_post_relation_id n°88833 set entity_id = 1308430
Update entity_post_relation_id n°88844 set entity_id = 94118132
Update entity_post_relation_id n°88854 set entity_id = 83096567
Update entity_post_relation_id n°88858 set entity_id = 5300208
Update entity_post_relation_id n°88861 set entity_id = 205202
Update entity_post_relation_id n°88865 set entity_id = 68048793
Update entity_post_relation_id n°88885 set entity_id = 49862535
Update entity_post_relation_id n°88888 set entity_id = 71079731
Update entity_post_relation_id n°88904 set entity_id = 61113754
Update entity_post_relation_id n°89051 set entity_id = 64410682
Update entity_post_relation_id n°88916 set entity_id = 83439860
Update entity_post_relation_id n°88941 set entity_id = 1135825
Update entity_post_relation_id n°88945 set entity_id = 82084561
Update entity_post_relation_id n°88962 set entity_id = 60415582
Update entity_post_relation_id n°88993 set entity_id = 49563561
Update entity_post_relation_id n°88973 set entity_id = 82571488
Update entity_post_relation_id n°88897 set entity_id = 57716540
Update entity_post_relation_id n°88954 set entity_id = 70819130
Update entity_post_relation_id n°88959 set entity_id = 3288996
Update entity_post_relation_id n°89012 set entity_id = 648747
Update entity_post_relation_id n°89007 set entity_id = 97296082
Update entity_post_relation_id n°89009 set entity_id = 5086011
Update entity_post_relation_id n°88827 set entity_id = 75203192
Update entity_post_relation_id n°89072 set entity_id = 57738297
Update entity_post_relation_id n°89035 set entity_id = 85100166
Update entity_post_relation_id n°89038 set entity_id = 48313271
Update entity_post_relation_id n°89062 set entity_id = 79569966
Update entity_post_relation_id n°89098 set entity_id = 73497060
190
 
Procédure PL/SQL terminée avec succès.
 
Pas d'erreur.
 
=== Done 11/05/2010 09:42:59 ========
 
Ecoulé : 00 :00 :05.81
11/05/2010-09:42
--------------------------------------------------------------------
Execution du script V68_0_2_APP-29492_ALL_correction_des_entity_post_relation.sql sur la base OLTPES
--------------------------------------------------------------------
 
=== Start 11/05/2010 09:43:00 ========
 
Connecté.
Update entity_post_relation_id n°103202 set entity_id = 21571317
1
 
Procédure PL/SQL terminée avec succès.
 
Pas d'erreur.
 
=== Done 11/05/2010 09:43:00 ========
 
Ecoulé : 00 :00 :00.29
11/05/2010-09:43
--------------------------------------------------------------------
Execution du script V68_0_2_APP-29492_ALL_correction_des_entity_post_relation.sql sur la base OLTPUK
--------------------------------------------------------------------
 
=== Start 11/05/2010 09:43:00 ========
 
Connecté.
0
 
Procédure PL/SQL terminée avec succès.
 
Pas d'erreur.
 
=== Done 11/05/2010 09:43:00 ========
 
Ecoulé : 00 :00 :00.30
11/05/2010-09:43
Fin du script
Commentaire de Julien Girardet [ 12/mai/10 11:26 ]
C'est ok pour nous (BI), script passé sur notre base.
Merci.




[BIN-566] [Partners] : Création d'un rapport pour Kelkoo Création: 04/mars/09 15:08  Mise à jour: 08/juin/09 15:08  Résolue: 03/juin/09 12:12

Etat: Fermé
Projet: Business Intelligence
Composants: Partners
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Ghislain Gridel Attribution: Geoffroy Vigneron
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word DMR - Appel à facture Kelkoo.docx     Microsoft Word DMR - Appel à facture Kelkoo_1.1.docx     Microsoft Word DMR - Appel à facture Kelkoo_1.2.docx     Microsoft Word DMR+-+Appel+à+facture+Kelkoo_1.1.docx     JPEG File screenshot-1.jpg    
Pays:
FRA - France

 Description   
Salut,

En marge du deal Kelkoo comparateur en marque blanche, il a été négocié un deal de visibilité sur la vente sur Kelkoo.fr. Il y aura un bloc en bas de toute les pages. Ci-joint un exemple de création. Leur rémunération sera la suivante :

- 6 euros par nouveau membre actif priceminister
--> rapport Xiti car membre actif est un e notion Xiti en first tracking
- 5% de commission sur les ventes générées dans un délai de 30 jours suivant le clic de l'utilisateur sur Kelkoo.
--> Rapport BI

Il faudrait donc inclure dans ce rapport le Volume d'Affaire hors frais de port capturé en last tracking 30 jours. Idéalement il faudrait rajouter leur commission en calculant directement les 5%.
Le code de tracking est le suivant 2232140.

A votre dispo pour toute question.
Ghislain


 Commentaires   
Commentaire de Agathe Remy [ 04/mars/09 19:56 ]
Bonjour Ghislain,

Si je comprends bien ta demande, il faudrait mettre en place un appel à facture pour le deal Kelkoo sur la vente.
Pour cela, j'aurais besoin que tu me précises les points suivants :
- Quand ce deal doit être mis en place sur le site ?
- Quand doit-on leur envoyé leur 1er appel à facture?
- Est-ce qu'un envoi le 5 de chaque mois (comme pour les autres partenaires de tracking) te conviendrait?
- L'appel à facture se base-t-il sur un tracking ou un groupe de tracking?
- Tu parles d'inclure un indicateur dans un rapport BI : de quel rapport parles-tu? Peux-tu nous donner son emplacement et son nom?
- Tu parles d'un deal sur la vente. Peux-tu donc me confirmer que dans ce cas, la notion de last tracking 30 jours signifie "il s'est écoulé maximum 30j entre le dépôt du cookie et le dépôt de l'annonce par le vendeur"? (et pas "il s'est écoulé maximum 30j entre le dépôt du cookie et l'achat effectué par l'acheteur"). Si oui, as-tu bien conscience qu'une vente peut survenir plusieurs mois après le dépôt d'une annonce?
- Avez-vous besoin d'un appel à facture pour la rémunération du deal comparateur en marque blanche?

A ta dispo si tu as des questions!

Agathe
Commentaire de Agathe Remy [ 09/mars/09 14:22 ]
Bonjour Ghislain,

Si cette demande est réellement majeure, il faudrait que tu répondes aux questions ci-dessus...

Merci.
Agathe
Commentaire de Ghislain Gridel [ 20/mars/09 16:23 ]
Bonjour Agathe,

j'attendais un retour de mon contact qui est en vacances... Ci-dessous les réponses à tes questions :
Quand ce deal doit être mis en place sur le site ?
--> il sera mis en place le 1er avril sur Kelkoo
- Quand doit-on leur envoyé leur 1er appel à facture?
--> Le 1er appel à facture devra être envoyé début mai. (par moi ou BI - a voir)
- Est-ce qu'un envoi le 5 de chaque mois (comme pour les autres partenaires de tracking) te conviendrait?
--> Oui, si on peut inclure la notion de nouveau membre actif dans BI.
- L'appel à facture se base-t-il sur un tracking ou un groupe de tracking?
--> L'appel à facture se base sur le groupe de tracking Kelkoo-Vente.
- Tu parles d'inclure un indicateur dans un rapport BI : de quel rapport parles-tu? Peux-tu nous donner son emplacement et son nom?
--> Je ne comprends pas.
- Tu parles d'un deal sur la vente. Peux-tu donc me confirmer que dans ce cas, la notion de last tracking 30 jours signifie "il s'est écoulé maximum 30j entre le dépôt du cookie et le dépôt de l'annonce par le vendeur"? (et pas "il s'est écoulé maximum 30j entre le dépôt du cookie et l'achat effectué par l'acheteur"). Si oui, as-tu bien conscience qu'une vente peut survenir plusieurs mois après le dépôt d'une annonce?
--> Après discussion, il s'agit bien du volume d'affaire achat capturé hors frais de port hors CBV, en last tracking 30 jours. (et non le VA généré par les vendeurs)
- Avez-vous besoin d'un appel à facture pour la rémunération du deal comparateur en marque blanche?
--> cette question concerne Benjamin. Mais dans ce cas c'est Kelkoo qui fera un appel à facture à PM (ils nous reversent un revenu)

Par ailleurs, peut-être peut-on prendre toute l'info dans BI ?
Voilà le contenu de l'appel à facture :
tracking groupe | Volume d'affaire | Nouveaux membre actif | Revenus Kelkoo

tracking groupe : Kelkoo vente
Volume d'affaire ; volume d'affaire achat capturé hors frais de port hors CBV, en last tracking 30 jours
Nouveau membre actif : un nouveau membre actif est un nouvel acheteur ou un nouveau vendeur
Revenus Kelkoo : 6¿ par Nouveau membre actif +5% du VA

A ta dispo
ghislain
Commentaire de Ghislain Gridel [ 20/mars/09 16:45 ]
il faut donc :
- un appel à facture envoyé le 5 du mois
- un reporting hebdo envoyé tous les lundis

destinataire :
njornet@yahoo-inc.com
en copie :
comparateur@priceminister.com

Merci !
Commentaire de Dalila Belkebir [ 16/avr./09 16:38 ]
Ghislain,

Nous sommes en cours de rédaction des spécifications et voici ce que nous venons de voir ensemble :
- le VA capturé HT, hors CBV, hors frais de port
- le tracking du panier à 30 jrs (comme pour Pangora)


Il nous manque des précisions sur ce que tu considères comme un membre actif.
Etant une notion XITI et comme vu avec toi, tu vas demander à Swan ce qui est précisément considéré comme membre actif (le but du jeu étant de ressortir les mêmes données que XITI afin de les comparer).

Je te propose donc de mettre à disposition les spécifications dans le JIRA .
Cette première version des spécifications ne comprendra pas la notion de membre actif que nous ajouterons dans une version ultérieure quand tu nous aura fourni les éléments nous permettant de le calculer.

Ces spécifications seront disponibles d'ici 17h30 ce jour pour validation.
Cela nous permettra d'avancer sur les développements du rapport et de te le mettre à disposition rapidement.


A ta disposition pour en reparler.

Cdlt,
Dalila.
Commentaire de Cyril Tanneau [ 16/avr./09 16:50 ]
Guislain,

Voici les spécification concernant les rapports "Kelkoo - appel à facture ", pour les versions hebdo et mensuelles.

En attente de ta validation,

merci,

Cyril
Commentaire de Ghislain Gridel [ 17/avr./09 09:54 ]
SAlut,

peut-on mettre le nombre de membres actifs directement dans BI ? et du coup l'insérer dans l'appel à facture avec le volume d'affaire ? et du coup calculer la rémunération total partenaire ?

Peut-on avoir le détail par code de tracking ?

Définition d' un membre actif : le membre est devenu actif. Il a effectué une première action : soit une vente effective, ou un premier achat.

Ghislain
Commentaire de Ghislain Gridel [ 17/avr./09 10:03 ]
le membre actif est en first tracking
Commentaire de Cyril Tanneau [ 17/avr./09 10:25 ]
Guislain, Dalila,

Voici la nouvelle version de la spec incluant la rémunération pour les nouveaux membres actifs.

merci :-)
Commentaire de Dalila Belkebir [ 17/avr./09 10:26 ]
Ghislain,

Nous avons pris en compte tes retours ce matin dans la nouvelle version des spécifications (v1.1) que nous venons d'associer au jIRA :
- définition du membre actif
- ajout des codes trackings dans le corps du tableau au lieu du groupe de tracking.

Merci donc de nous les valider asap afin de débuter les développements.

A ta disposition pour d'éventuels retours.

cdlt,
Dalila.
Commentaire de Ghislain Gridel [ 17/avr./09 10:42 ]
qq modifs rapides ci-jointes. a ta dispo
Commentaire de Cyril Tanneau [ 17/avr./09 11:34 ]
Guislain, Dalila,

les modifications ont été apportées à la spécification en fonction des remarques de Ghislain.

La version finale de la spec est donc disponible à partir du lien :

http://pricejira.lan/secure/attachment/31698/DMR+-+Appel+%E0+facture+Kelkoo_1.2.docx

Merci,

Cyril
Commentaire de Ghislain Gridel [ 17/avr./09 12:10 ]
ok pour moi. merci
Commentaire de Dalila Belkebir [ 05/mai/09 09:39 ]
Bonjour Ghislain,

Nous avons mis en production le rapport Kelkoo hier.

A cause de limitations techniques, la version disponible ne comporte pas les informations relatives aux membres actifs.
En effet, il s'agit d'une notion assez complexe à mettre en ¿uvre car elle implique la mise en place de processes d'alimentation et de dénormalisation.
Ces processes là ne peuvent être mis en place dans le cadre d'un JIRA mais nécessitent un mini projet à prioriser avec Agathe.


La planification des rapports hebdo et mensuel est mise en place.

merci donc de tes retours pour validation.

Cdlt,
Dalila.
Commentaire de Ghislain Gridel [ 05/mai/09 11:07 ]
Merci Dalila. Odile planifiera ce projet avec Agathe.
Commentaire de Dalila Belkebir [ 06/mai/09 18:11 ]
Ghislain,

Juste une petite question : l'appel à facture doit être fourni au format excel ou bien pdf (impossible de le modifier par le partenaire)?
Pour le moment il est fourni au format excel si cela ne te convient pas, il s'agit tout simplement de modifier le format dans la planification.

Cdlt,
Dalila.
Commentaire de Ghislain Gridel [ 12/mai/09 10:32 ]
Bonjour,
étant donné que l'appel à facture mensuel est incomplet (il manque les membres actifs), cela ne sert à rien de l'envoyer. Je l'ai fait moi-même à la main du coup. En revanche je me sers du montant du VA hors frais de port indiqué dans ce fichier.

Pouvez-vous donc retirer les destinataires Kelkoo de l'appel à facture mensuel et laisser mon email svp ?

Merci !

Ghislain
Commentaire de Dalila Belkebir [ 12/mai/09 11:38 ]
Bonjour Ghislain,

C'est fait.

Cdlt,
Dalila.
Commentaire de Agathe Remy [ 28/mai/09 17:12 ]
Bonjour Ghislain,

Dans les spécifications que tu as validé, un membre actif était défini comme :
- Un nouvel acheteur, c'est-à-dire un PriceMember en first tracking ayant effectué son premier achat capturé au cours de la période étudiée
OU
- Un nouveau vendeur, c'est-à-dire un PriceMember en first tracking ayant effectué sa première vente capturée au cours de la période étudiée

Hors il s'avère que suite à nos derniers échanges, il me semble que la règle de gestion correcte est:
- Un nouvel acheteur, c'est-à-dire un PriceMember en first tracking ayant effectué son premier achat autorisé au cours de la période étudiée
OU
- Un nouveau vendeur, c'est-à-dire un PriceMember en first tracking ayant effectué sa première vente confirmée au cours de la période étudiée

S'il te plait, peux-tu me confirmer cette nouvelle règle de gestion?

Nous disposons dans le BI de toutes les données pré-calculées permettant d'implémenter cette dernière règle de gestion. Dans ce cas, nous n'aurons donc aucun problème à l'intégrer aux rapports Kelkoo.

Merci.
Agathe
Commentaire de Agathe Remy [ 28/mai/09 17:31 ]
J'en profite également pour te demander de confirmer le modèle de rémunération.
En effet, le contrat spécifie :
5% de commissions sur les ventes générées dont la traduction juridique est la suivante : VA capturé TTC, frais de ports inclus, hors CBV
Hors, dans les spécifications de Kelkoo (et donc le rapport), nous avons la définition suivante : VA capturé HT, hors frais de port, hors CBV (modèle de rémunération de Nextag)

S'il te plait, peux-tu nous indiquer quelle est la règle de gestion correcte?

Merci.
Agathe
Commentaire de Ghislain Gridel [ 28/mai/09 17:43 ]
merci Agathe,

dans le cadre du deal kelkoo, on souhaite les rémunérer si PM gagne de l'argent donc c'est forcément du capturé.

En revanche sur la définition du membre actif, on peut la caler sur celle de Xiti, qui doit être de l'autorisé (à confirme pas Swan)
Commentaire de Ghislain Gridel [ 28/mai/09 18:13 ]
voilà :
Un nouvel acheteur, c'est-à-dire un PriceMember en first tracking ayant effectué son premier achat autorisé au cours de la période étudiée
OU
- Un nouveau vendeur, c'est-à-dire un PriceMember en first tracking ayant effectué sa première vente confirmée au cours de la période étudiée

dans le contrat, on parle bien de VA capturé TTC, frais de ports inclus, hors CBV

Merci
Commentaire de Agathe Remy [ 28/mai/09 18:29 ]
Geoffroy,

S'il te plait, peux-tu prendre en compte les corrections sur :
- les nouveaux membres actifs
- le calcul du VA
?
Il s'agit de mettre à jour les spécifications, ainsi que les rapports hebdos et mensuels.

Merci.
Agathe
Commentaire de Geoffroy Vigneron [ 03/juin/09 12:12 ]
Ghislain,

Pourras - tu valider l'appel à facture mensuel qui sera généré le 05 juin 2009?

Merci.

Cordialement,
Geoffroy

Commentaire de Ghislain Gridel [ 08/juin/09 15:01 ]
ok. merci.
Commentaire de Agathe Remy [ 08/juin/09 15:08 ]
Merci!




[BIN-413] [Seller debt] : Réconcilier la dette vendeurs sur 2007/12 et 2008/01 Création: 18/févr./08 11:17  Mise à jour: 29/avr./08 17:33  Echéance: 22/févr./08 00:00  Résolue: 29/avr./08 17:26

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Agathe Remy Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Ecarts sur la réconciliation de la dette vendeur sur décembre 2007 :
- l'équipe BI doit investiguer ; => Retour prévu avant le 23/02/2008
- l'équipe Comptable doit faire la réconciliation sur janvier 2008 ;

Voir s'il y a lien un lien avec le bug des compensations vendeurs exemptés de TVA?!

 Commentaires   
Commentaire de Romain Czornomaz [ 28/févr./08 11:16 ]
La dette vendeur a été réconciliée de notre cote jusqu'à Janvier 2008 inclus.
Dans les reste à faire, nous devons comparer nos résultats à ceux de Claudie.


Commentaire de Agathe Remy [ 12/mars/08 10:56 ]
Il subsiste des écarts entre les données calculées par l'équipe BI et l'équipe Finance. Pour le calcul du volume d'affaires, nous nous basons sur des rapports différents.

Nous devons investiguer pour comprendre d'où proviennent les écarts entre les rapports « payment by purchase » et « purchase summary by month ». Les écarts représentent 372 ¿ en 2007.
Commentaire de Romain Czornomaz [ 29/avr./08 17:33 ]
La dette vendeur a été réconciliée jusqu'au 1 Mars 2008.

Pour Philippe, il est nécessaire de passer sur les chantiers restants. Si des écarts significatifs sont découverts, la demande pourra être réouverte.

Romain




Déploiement Infoglue - lot PM-IG-0.1 (EXP-997)

[EXP-1003] Modification du DNS de la zone priceminister.com Création: 24/janv./06 12:22  Mise à jour: 25/juin/07 18:55  Résolue: 30/janv./06 10:43

Etat: Résolu
Projet: Exploitation
Composants: Installation
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Sébastien Tournay Attribution: Ranto Andriambololona
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Faire la demande à JMH pour créer le nom cms.priceminister.com. On peut utiliser la VIP '212.23.167.55' (utilisée aussi pour bo et bi.priceminister.com)

 Commentaires   
Commentaire de Ranto Andriambololona [ 24/janv./06 12:34 ]
Je viens de faire la demande à JET pour l'ajout DNS et VIP

>MEP-005198

>Bonjour,
>Merci de mettre en place la nouvelle entrée cms.priceminister.com dans nos DNS

>VIP
>212.23.167.55

>RIPS
>Dans /etc/hosts de
>Phaeton
>212.23.167.8 bo.priceminister.com intra.priceminister.com bi.priceminister.com cms.priceminister.com
>Cupidon
>212.23.167.33 bo.priceminister.com bi.priceminister.com cms.priceminister.com
Commentaire de Ranto Andriambololona [ 24/janv./06 14:39 ]
La demande a été traité par Jet, j'ai vérifié manuellement c'est OK
Commentaire de Sébastien Tournay [ 24/janv./06 17:27 ]
En fait le nom plus adaptée serait 'eglue.priceminister.com' peux tu faire la demande à JMH pour qu'il puisse faire le changement ?

Merci d'avance

Sébastien
Commentaire de Ranto Andriambololona [ 25/janv./06 11:01 ]
Demande effectuée et manip réalisée par JET




[APP-32152] La propriété priceminister.product.redirection.prd_status_code_list est commentée en ES / UK Création: 08/déc./10 16:24  Mise à jour: 10/déc./10 16:40  Résolue: 09/déc./10 14:33

Etat: Fermé
Projet: Application PriceMinister
Composants: Référencement
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 83.0.0 (VEN-F)

Type: Bogue Priorité: Majeur
Rapporteur: Thierry Leforestier Attribution: Jean-Sébastien Franck
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
GBR - Royaume Uni, ESP - Espagne
Site: Prod
Projets PM: *** A PLANIFIER ***
Navigateur: Tous

 Description   
La propriété est commentée ou vide en ES et UK :
priceminister.product.redirection.prd_status_code_list

Merci de la reinseigner avec le prd_status_code 50

Est-ce qu'on peut traiter le status conflit par ce biais ?

Merci !

 Commentaires   
Commentaire de Jean-Sébastien Franck [ 09/déc./10 14:33 ]
J'ai modifié la propriété en ES et UK, elle sera active en prod lors de la sortie de la VEN-F.

Le statut conflit peut également être géré par ce biais. Attention, en ce qui concerne les fusions de FP, il y a déjà des redirections qui sont faites mais on ne se base pas sur le statut du produit mais sur la valeur du champ target_product_id du produit. Si tu veux faire des redirections pour les produits fusionnés, il est donc inutile de modifier la propriété, c'est déjà géré.

Pour que ce soit plus clair, voici les règles qui sont appliquées quand tu affiches une FP :
1) si le produit a un target_product_id (cas des fusions de FP), on fait une redirection
2) si le produit a un statut présent dans la liste priceminister.product.redirection.prd_status_code_list, on fait une redirection
3) les autres règles de redirection : checks urlname etc




[BIN-405] [Espagne] Demande de Rapport : taux de réachat Espagne Création: 01/févr./08 12:33  Mise à jour: 23/mai/08 16:29  Résolue: 18/févr./08 17:23

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Charles Decaux Attribution: Florian Ambrosi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à BIN-448 [First tracking] : amélioration du ra... Ouvert
Pays:
ESP - Espagne

 Description   
Bonjour,

un indicateur important pour le marketing est le taux de réachat.

Cette info est disponible sur la France grâce aux rapports Titan.
Sur l'Espagne, nous n'avons pas cette info car pas de rapports Titan.

Il faudrait donc mettre en place un rapport BI nous donnant :
- le taux de réachat global site
- le taux de réachat par tracking et groupe de tracking

Merci et à votre dispo pour en parler

Charles

 Commentaires   
Commentaire de Agathe Remy [ 05/févr./08 15:06 ]
Charles,

Peux-tu nous donner le chemin d'accès dans l'intranet du ou des rapports titan au(x)quel(s) tu fait allusion?

Merci:-)

Agathe
Commentaire de Charles Decaux [ 05/févr./08 17:03 ]

http://intra.priceminister.com/stats/reports/confid/Big_Buyers/
Commentaire de Agathe Remy [ 07/févr./08 12:26 ]
Charles,

Ce rapport peut être fait sous BI. En revanche, comme pour l'autre JIRA, le rapport auquel tu fais allusion ne possède aucune information de tracking ou groupe de tracking.
S'agit-il donc d'une demande de nouveau rapport? Et si oui, pourrais-tu la spécifier de façon un peu plus précise?

Je suis à ta dispo pour en discuter:-)

Agathe
Commentaire de Charles Decaux [ 08/févr./08 09:41 ]
Ok merci.

Tant pis si je ne l'ai pas par tracking, je serait déjà content de l'avoir "global site".
Veux-tu que je passe te voir pour que tu me montres les indicateurs à utiliser pour avoir ce rapport sous BI ?

Merci

Commentaire de Agathe Remy [ 11/févr./08 18:40 ]
Charles,

D'après notre discussion, tu serai intéressé par le taux de réachat par first tracking. Peux-tu me le confirmer?
De plus, veux-tu que nous considérions les achats autorisés ou capturés?

Merci:-)

Agathe
Commentaire de Florian Ambrosi [ 12/févr./08 15:53 ]
Agathe,

J'ai bien modifier les rapports avec tes modifications.
Je fais un petit rappel car tout était fait par email auparavant.
Les modifications demandées :

- Renommer le rapport en « Purchase frequency by first tracking group » (modifier également le titre du rapport et le nom de l'onglet)
- Ajouter le filtre « Captured purchase » et supprimer la condition « Captured purchase count >= 1)
- Agrandir la largeur de la cellule de section
- Ajouter le panier moyen (Avg purchase = Captured GMS/Captured purchase)
- Renommer les en-têtes de colonne
- Ajouter un total pas tracking (pied de tableau)

Pour rappel, les rapports se situent dans la partie Développement/First Tracking, pour le premier et dans Développement/Purchase pour le second.
Les specs se situent quand à elle dans "V:\Reporting\BusinessIntelligence\Evolutions\Purchase frequency".

Florian
Commentaire de Florian Ambrosi [ 18/févr./08 17:23 ]
Agathe

Le rapport à valider.

Merci.
Commentaire de Agathe Remy [ 21/févr./08 14:51 ]
Charles,

Les rapports suivants ont été livrés en Espagne :
- "Purchase frequency by first tracking group" dans le répertoire Dossiers publics/Spain/First tracking
- "Purchase frequency" dans le répertoire Dossiers publics/Spain/Purchase

Peux-tu nous dire s'ils te conviennent?
Surtout que certains les attendent en France...

Merci:-)

Agathe
Commentaire de Agathe Remy [ 28/févr./08 11:01 ]
Charles,

Peux-tu nous faire un retour sur ces rapports afin que nous puissions les livrer également en France?

Merci.

Agathe
Commentaire de Charles Decaux [ 05/mars/08 19:07 ]
Merci à vous, je valide les rapports
Commentaire de Agathe Remy [ 12/mars/08 11:50 ]
A la demande d'Odile, nous avons renommé les rapports en "Buyers distribution by purchase count".
Les 2 rapports ont également été déployés en France.




[BIN-6] Installation serveur base de données Création: 12/déc./05 19:31  Mise à jour: 14/sept./07 16:55  Echéance: 30/déc./05 00:00  Résolue: 02/août/06 16:45

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Agathe Remy
Résolution: Corrigé  
Σ Estimation restante: 1 heure, 30 minutes Estimation restante: Non spécifié
Σ Temps consacré: 1 jour, 7 heures, 50 minutes Temps consacré: Non spécifié
Σ Estimation originale: 2 jours Estimation originale: Non spécifié

Liens des demandes:
Dépendance
est bloqué par BIN-24 Vérifier la présence de Tibi Arié la ... Fermé
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
BIN-7 Installation de la partie serveur Red... Sous-tâche Fermé Agathe Remy  
BIN-8 Installation des bases de données en ... Sous-tâche Fermé Agathe Remy  
BIN-9 Installation d'Oracle Workflow Server Sous-tâche Fermé Agathe Remy  
BIN-10 Installation d'Oracle Warehouse Builder Sous-tâche Fermé Agathe Remy  
BIN-11 Déploiement des développements OWB Sous-tâche Fermé Agathe Remy  
BIN-12 Initialisation de l'ODS Sous-tâche Fermé Agathe Remy  
BIN-13 Initialisation du DataWareHouse Sous-tâche Fermé Agathe Remy  
BIN-14 Test du chargement journalier Sous-tâche Fermé Agathe Remy  
BIN-26 Etude de la possibilité d'utiliser MO... Sous-tâche Fermé Agathe Remy  
BIN-27 Finalisation installation de LATONE Sous-tâche Fermé Agathe Remy  
BIN-28 Validation des outils de sauvegarde B... Sous-tâche Fermé Agathe Remy  
BIN-43 Envoi des mails d'alerte OWB Sous-tâche Fermé Jérémie Bennejean  
BIN-44 Résolution problème bloquant Sous-tâche Fermé Patrick Pereira  

 Description   
Installation de la partie Base de données pour le projet BI




[BIN-254] comptage des PMV avec de l'argent disponible Création: 26/déc./06 17:53  Mise à jour: 14/sept./07 17:33  Résolue: 19/janv./07 16:27

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut,

j'ai récemment fait un comptage sur BI pour connaitre le nb de personnes ayant des PMV avec de l'argent dessus.
Ce nb est inférieur à 7000, ce qui ne correspond pas à la réalité.
Est-ce que vous pouvez jeter un oeil à ma requête pour voir si je n'ai pas fait une erreur (dossier Alexandra /PMV positifs ) ?
Merci
Alexandra

 Commentaires   
Commentaire de Alexandra Viravaud [ 02/janv./07 11:21 ]
Hello !

Nous avons résolu le pb sur le comptage et nous arrivons à environ 70 000 personnes.

Je souhaite maintenant ajouter la condition suivante : "la personne est abonnée" :
- à au moins une newsletter (ht, culturelle, maison et loisir)
et/ou
- à la relance vieux acheteurs
et/ou
- à la relance acheteurs déçus

Comment mettre en place sur BI la condition et/ou relative à l'abonnement ?
Merci
Alex




[BIN-505] [Tracking] : Extraction des last tracking d'une sélection de paniers pour comparaison avec DI Création: 22/oct./08 17:59  Mise à jour: 24/nov./08 16:57  Résolue: 18/nov./08 18:25

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Agathe Remy Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel extraction panier tracking pour GGR le 30102008.xls     Microsoft Excel PURCHASE ID.xls    
Liens des demandes:
Duplicate
a pour doublon BIN-520 [Tracking] : étude comparative DI / BI Fermé
Pays:
FRA - France

 Description   
Bonjour Agathe et Dalila,

Je mène un étude sur les différences de trackings entre DI et BI. DI est l'outil de tracking de Nextedia, notre agence de liens sponsorisés, qui mesure aussi le ref nat. J'ai pris 2000 paniers au hasard sur la journée d'hier que j'ai transmis à Nextedia pour qu'ils me donneNt le tracking associés à ces paniers chez eux.
J'aimerai moi aussi trouver les last tracking 30 jours de ces paniers chez nous. Comment faire ça rapidement ?

Merci de votre retour

Ghislain


 Commentaires   
Commentaire de Agathe Remy [ 22/oct./08 18:16 ]
Bonjour Ghislain,

S'il te plait, peux-tu nous préciser l'objectif de ton étude sur les différences entre DI et BI afin que nous puissions au mieux répondre à ta demande? Par exemple, ton objectif est-il d'évaluer combien de paniers ont des trackings différents sur un échantillon de 2000?
Pour rappel, DI et BI n'affectent pas les trackings de la même manière au panier puisque DI n'écrase pas les trackings LS avec les trackings Marketing et inversement BI n'écrase pas les trackings Marketing ou LS par le réferencement naturel.

Peux-tu également me confirmer que la demande consiste à te fournir la liste des last trackings 30 jours associés aux paniers listés dans le tableau Excel ci-joint?

Enfin, peux-tu préciser le niveau d'urgence (pour quand en as-tu besoin? est-ce que Nextedia t'a fournit une date de livraison?) et de priorité de ta demande (Mineur, Majeur, etc...) en fonction de l'objectif business?

Merci.

Agathe
Commentaire de Ghislain Gridel [ 22/oct./08 18:48 ]
Agarthe, suite à notre discussion :
Objectif : évaluer combien de paniers ont des trackings différents sur un échantillon de 2000 paniers
Demande: Fournir la liste des last trackings 30 jours associés aux paniers listés dans le tableau Excel ci-joint
Niveau d'urgence : assez urgent. J'attends un retor de Nextedia à ce sujet

Par ailleurs, il y aura aussi un lot 2 avec 2000 autres paneirs extraits de DI.

Merci !
Commentaire de Dalila Belkebir [ 30/oct./08 17:59 ]
Ghislain,

Voici l'extraction (en PJ) que j'ai réalisée à partir des ID paniers que tu as fournis.
N'hésites pas à me faire tes retours.

Cordialement,
Dalila.
Commentaire de Ghislain Gridel [ 30/oct./08 18:05 ]
Merci. c'est impecable. Je te tiens au courant.
Commentaire de Agathe Remy [ 13/nov./08 18:33 ]
Bonjour Agathe,

Nous t'enverrons demain 5 échantillons de paniers tirés de Decisive Insight
- 2000 paniers tirés de l'ensemble des canaux
- 2000 paniers LS hors marques
- 2000 paniers LS marque
- 2000 paniers ref nat marque
- 2000 paniers ref nat hors marque

L'objectif sera de mesurer les écarts de chiffres entre DI et BI
Pour chaque fichier nous comparerons :
- id panier
- date du panier
- last tracking 30 jours
- volume d'affaire
- commission

Penses-tu pouvoir revenir vers nous là-dessus demain dans la journée ?
Nous attendons les fichiers de l'agence pour début de matinée

D'avance merci
Mathieu
Commentaire de Agathe Remy [ 13/nov./08 18:39 ]
Mathieu,

Le volume d'affaires et la commission que tu veux comparer sont-ils :
- autorisé ou capturé ?
- avec ou sans frais de port ?
- avec ou sans TVA ?

Merci de tes retours.
Agathe
Commentaire de Odile Szabo [ 13/nov./08 19:02 ]
Agathe,

Les écarts de VA et com qu'on veut mesurer sont ceux que l'on prend habituellement dnas le rapport purchase tracking by month donc c'est de l'autorisé, hors frais de port et sans tva (c'est bien ça qu'on a dans purchase tracking by month?).
cette demande est prioritaire devant les autres car les réponses sont essentielles pour nous aider à prendre la bonne décision sur la dedup ref nat et le pilotage des campagnes mots clés (idéalement si on a l'info pour notre dej du 20 avec Swan ça serait top!). bref, notre deadline est le 21/11. c'est jouable pour toi? dis moi si tu as un pb,
merci
odile
Commentaire de Dalila Belkebir [ 17/nov./08 18:11 ]
Heu .... sauf erreur de ma part je ne vois pas les ID des paniers sur lesquels requêter ....

Pouvez-vous SVP les attacher à la demande ?
Cela me permettra de les générer maintenant.

Merci.

Dalila.
Commentaire de Dalila Belkebir [ 18/nov./08 18:25 ]
Demande traitée dans le JIRA 520. Voir le fichier attaché au JIRA 520.

Cordialement,
Dalila.




[BIN-550] [BACK-OFFICE] ajout dimensions précalculées? Création: 19/janv./09 11:39  Mise à jour: 16/févr./10 10:03

Etat: Ré-ouvert
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
JIRA sous la forme d'une question.

Qqch qui est disponible directement dans le BO mais qu'on est obligé de recalculer systematiquement dans le BI, c'est le taux de réclamation et le taux d'acceptation d'un vendeur.

Serait-il possible d'avoir des dimensions prédéfinies dans l'univers ITEM?

Un claim ratio: rapport entre les item capturés ayant une claim accepted et les autres
Un acceptation ratio: rapport entre les items authorized et les items cancelled (seller_refused et seller_commit_timeout uniquement , pas les négo refusées)

Merci.

 Commentaires   
Commentaire de Agathe Remy [ 19/janv./09 13:19 ]
Bonjour Cédric,

Nous pouvons en effet ajouter des indicateurs pré-définis pour ces ratios.
Attention, comme ce sont des indicateurs, leur sens varie en fonction des dimensions sélectionnées dans le rapport (périmètre de l'analyse).
Dans le BO, le périmètre de la fiche d'un vendeur est fixe, contrairement au BI où cela dépend des dimensions (axes d'analyse) sélectionnées.
Ainsi, pour avoir le taux d'acceptation d'un vendeur, il ne faudra pas oublier de sélectionner l'identifiant du vendeur (ou son pseudo), sinon il te calculera le ratio par mois ou autre dimension sélectionnée...

Autre remarque, le nb d'items capturés ayant une réclamation acceptée varie dans le temps puisqu'une réclamation peut être réouverte, même plusieurs années plus tard.

Ayant déjà plusieurs JIRAs en cours, je planifierai la réalisation de ta demande à partir de la semaine prochaine.

A ta dispo si tu as d'autres questions.

Agathe
Commentaire de Cedric Favero [ 19/janv./09 14:49 ]
çà me va.

"Ainsi, pour avoir le taux d'acceptation d'un vendeur, il ne faudra pas oublier de sélectionner l'identifiant du vendeur "
=> ce sera toujours par rapport à un pseudo bien sur.


"Autre remarque, le nb d'items capturés ayant une réclamation acceptée varie dans le temps puisqu'une réclamation peut être réouverte, même plusieurs années plus tard. "
=> comme en BO d'ailleurs :-)
Commentaire de Cedric Favero [ 19/janv./09 14:51 ]
Par compte, apres reflexion,il me faudrait plutot un "Cancel Ratio" qu'un "Acceptation Ratio" (meme chose à l'envers)
(attention à n'inclure dans les cancelled que ceux refusés par le vendeur ou en time_out)

Merci d'avance.
Commentaire de Dalila Belkebir [ 14/août/09 18:10 ]
Habib,

=> Concernant le "Cancel ratio", on a créé l'indicateur "Cancellation rate" dans la classe Financial Indicators, car cette dimension peut s'appliquer à un seller mais aussi à un buyer.
Cet indicateur permet de calculer le nombre d'articles annulés (hors négo) DIVISÉ PAR le nombre d'articles autorisés.

=> Concernant "rapport entre les item capturés ayant une claim accepted et les autres", on a créé l'indicateur Captured item claim rate dans la classe financial indicators.
Il permet de calculer le nombre d'items avec une claim acceptée sur le nombre d'items capturés.

Merci de ton retour pour validation.

Dalila.
Commentaire de Dalila Belkebir [ 17/sept./09 15:33 ]
Bonjour Habib,

Peux-tu me faire un retour sur ce JIRA afin de le clôturer ?
Merci de vérifier que les données calculées par les indicateurs sont bien correctes.

Cdlt,
Dalila.
Commentaire de Steven Harel [ 14/oct./09 14:46 ]
désolé pour le retour tardif.

le cancel ratio ne fonctionne pas. comme si on avait un ratio (cancelled/(cancelled + tous les autres)) avec "tous les autres" = 0. on a donc systématiquement des taux de 100%

c'est quoi pour vous des articles "autorisés" ?
chez nous c'est un statut temporaire de panier et pas d'article.

pour moi, le ratio devrait être calculé ainsi :

articles articles annulés/articles achetés

avec :

- articles annulés = cancelled avec juste les labels seller_refused et seller_commit_timeout

- articles achetés = committed + closed + on hold + (cancelled (seller_refused et seller_commit_timeout))
Commentaire de Cyril Tanneau [ 30/oct./09 10:14 ]
Steven,

Le taux d'annulation au niveau de l'article est calculé comme suit :

1-(nombre d'articles capturés hors négo/nombre d'articles autorisés hors négo)
Ou encore (les deux sont équivalents) :
(Nombre articles autorisés hors négo - nombre d'articles capturés hors négo) / nombre articles autorisés hors négo

Les articles (dans le BI) peuvent avoir les statuts suivants :
ITM_STATUS_CODE IDENTIFIER LABEL
10 RESERVED En attente de confirmation du vendeur
20 REQUESTED En attente de confirmation du vendeur
30 COMMITTED Le vendeur s'est engagé à livrer
40 CLOSED Reçu par l'acheteur
50 DELETED Supprimé
60 CANCELLED Annulé
70 ON_HOLD Réclamation en cours
100 REMINDED En attente de confirmation du vendeur

Les articles autorisés regroupent les statuts 20,30,40,60,70,100 (on exclut 10 et 50)
Les articles capturés regroupent les statuts 30,40,70

Ainsi, l'indicateur Cancellation rate répond à la formule ci-dessus. Par conséquent, il ne doit pas être utilisé dans un rapport n'ayant pas le filtre « Authorized items », afin d'éviter la division par 0.

Il y avait tout de même une erreur dans la formule de calcul de l'ancien indicateur, qui a été corrigée.

Je reste à votre dispo pour toute question.

Merci,

Cyril




[INF-262] installation plugin Firefox Java Runtime Environment Création: 05/févr./09 11:17  Mise à jour: 30/mars/09 15:06  Résolue: 30/mars/09 15:06

Etat: Résolu
Projet: Infrastructure
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Mathieu Richomme Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
salut Stéphane,
ce plugin est nécessaire pour modifier mes rapports BI
merci!
Mathieu

 Commentaires   
Commentaire de Stéphane Eccli [ 30/mars/09 15:06 ]
pouet




[INF-307] Excel 2007 pour JUG Création: 04/mai/09 17:11  Mise à jour: 12/mai/09 17:02  Résolue: 12/mai/09 17:02

Etat: Résolu
Projet: Infrastructure
Composants: Micro
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Bonjour,

Comme vu en point BI/Exploit et avec Philippe, il faudrait installer Excel 2007 sur le poste de Julien GIRARDET afin de lui permettre de traiter les demandes BI Finance.

Merci.
Agathe

 Commentaires   
Commentaire de Stéphane Eccli [ 12/mai/09 17:02 ]
ok pour excel




[BIN-446] [Executive] : Nouveau rapport de suivi du nombre d'acheteurs uniques sur les 1, 3 et 6 derniers mois Création: 22/mai/08 14:19  Mise à jour: 08/juil./08 11:02  Résolue: 30/mai/08 17:41

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File active_buyer.sql    
Pays:
FRA - France

 Description   
Il s'agit de transférer le rapport titan dans BI en ajoutant le nombre d'acheteurs uniques sur les 12 et 24 derniers mois, ainsi qu'une invite afin de sélectionner une date d'observation (i.e. avoir le nombre d'acheteurs uniques des 6 derniers mois au 1er janvier 2008 ou au 1er janvier 2007 par exemple).
Faire les spécifications fonctionnelles (DMR), puis techniques (DSD) et développer le rapport dans BusinessObjects en Développement.

Merci.

Agathe

 Commentaires   
Commentaire de Agathe Remy [ 22/mai/08 14:21 ]
Voici le script titan de génération du rapport que l'on veut migrer dans BI.
Commentaire de Cyril Tanneau [ 30/mai/08 17:41 ]
Le rapport est OK. Les résultats sont identiques à ceux de la requête sur l'integ.

merci,

Cyril
Commentaire de Cyril Tanneau [ 10/juin/08 17:04 ]
Le nombre de mois a été calculé à partir du nombre de jours. De cette façon, nous avons :

 - 1 mois = 30 jours
- 3 mois = 91 jours
- 6 mois = 183 jours
- 12 mois = 1 an = 365 jours
 
Merci,

 Cyril.
Commentaire de Cyril Tanneau [ 11/juin/08 16:51 ]
Bonjour,

le rapport est terminé. Il se nomme "Active buyers follow up" et est disponible:

- pour la France dans le dossier: France\Purchase;

- pour l'Espagne dans le dossier: Spain\Purchase.

Peux-tu valider le rapport?

Merci,

Cyril




[BIN-497] [Finance] : Ecart sur compensation par chèque - aout Création: 26/sept./08 14:32  Mise à jour: 10/oct./08 12:56  Résolue: 10/oct./08 12:56

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Samira Remila Attribution: Emeric Teil
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Agathe, Dalila,

Comme vu ensemble,sur le mois d'aout écart constaté sur emission des chq :

- rapport "compensation by method and closing date " : total payment = 402332,81
- fichier de suivi des chq émis du BO "fichier recollement" : total chq émis = 402323,04

soit un écart de 9.77 euros en trop sur le rapport BI
je vous envoie un mail avec le tableau récapitulatif
Pouvez-vous nous tenir informés rapidement
merci à vous
Samira

 Commentaires   
Commentaire de Samira Remila [ 30/sept./08 12:09 ]
Comme vu ensemble,sur le mois de septembre aussi j'ai un écart sur emission des chq :

- rapport "compensation by method and closing date " : total payment = 289138,16
- fichier de suivi des chq émis du BO "fichier recollement" : total chq émis = 288466,03

soit un écart de 672.13 euros en trop sur le rapport BI
Commentaire de Agathe Remy [ 03/oct./08 14:14 ]
Emeric,

Pourrais-tu, s'il te plait, commenter ce JIRA en décrivant le bug que vous avez identifié et me confirmer sa résolution à venir?

Merci.
Agathe
Commentaire de Dalila Belkebir [ 10/oct./08 12:56 ]
Effectivement,
Le problème est le suivant : certains vendeurs n'ont pas d'adresse de paiement (incohérence "historique" des données qu'on voit "remonter" suite au projet "inscription vendeur"). Les compensations pour ces vendeurs sont tout de même effectuées par le système et considérées comme "fermées".
Cependant, ces vendeurs n'ayant pas de coordonnées de paiement, le script de l'exploit qui génère le fichier de compensations ne prend pas en compte les compensations ainsi générées (sans adresse).

Ce qui nous concerne :
-> pour Aout : 1 compensation
-> pour Septembre : 6 compensations

Ci-dessous, ce qu'Arnaud a trouvé pour le mois de Septembre :
__________

"En effet, les compensations par chèque (1 en aout et 6 en septembre) qui n'ont pas d'adresse de paiement ont l'air de correspondre avec le décalage de paiement dont t'a parlé Philippe :

SELECT SUM(payment_total) FROM compensation where cmp_status_code => 40
and cmp_method_code = 10 and usr_privilege_code = 10 and usa_last_name IS NULL;

SUM(PAYMENT_TOTAL) = 681.9
____________

Les 7 comptes concernés :
LOGIN USR_PRIVILEGE_CODE
CREATION_DATE
-------------------------------------------------- ------------------
-------------------
ismav 40
09/10/2001 14:46:09
pailpail 40
06/03/2005 18:36:20
dda-l 40
23/12/2005 13:19:58
totove 40
15/11/2006 15:42:20
yann7950 40
11/12/2006 14:43:22
jupicat1 40
29/09/2007 21:44:01
MACULTURE 10
09/11/2007 20:26:37

On vous laisse trouver de votre côté un moyen pour régulariser ces situations. Du notre, on a déjà prévu de faire le nécessaire dans le cadre de la TX-C pour que cela ne se reproduise plus...

EMERIC.




[BIN-626] [PARAM] Les taux de reussite sont faux dans les rapports lorsque des lignes sont ignorées par les Imports Création: 20/août/09 16:33  Mise à jour: 28/sept./09 11:53  Résolue: 25/sept./09 15:56

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Frédéric Nahum Attribution: Geoffroy Vigneron
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
GBR - Royaume Uni, ESP - Espagne, FRA - France

 Description   
Je viens de me rendre compte que les rapports Import ne tienne pas compte des lignes ignorées

Ex : Prenons un fichier de 10 000 lignes.

Lignes totales : 10 000 lignes
Lignes traitées : 1 000 lignes
Lignes en erreurs : 100 lignes
Lignes ignorées : 8 900 lignes

Le taux de succès est donc de 99 % (lignes traitées + lignes ignorées) alors que dans le BI le taux de succès est de 10 % (car il ne tiens pas compte des lignes ignorées)
Donc il faudrait considérer les lignes ignorées comme des lignes traitées mais surtout pas comme des lignes en erreur pour les taux ne soient pas faussé

 Commentaires   
Commentaire de Frédéric Nahum [ 20/août/09 16:36 ]
Pour te donner un exemple de production le partenaire INTERNITY_FR est concerné par ce phénomène.
Il est dans le BI au alentour de 10 % de réussite alors qu'il devrait être à 88 %

Il y' a pas mal de fichier ou la majorité du fichier est ignorée (comme par exemple ignorer les stock à 0 et les mauvaises catégories)
Commentaire de Dalila Belkebir [ 18/sept./09 14:21 ]
Bonjour Frédéric,

Nous comptons modifier les dimensions dans les Univers. Voici la teneur de nos modifications :

L'indicateur "Rejected line count" calculé comme ça :
COUNT_ERRORS + COUNT_IGNORED
va devenir
COUNT_ERRORS

L'indicateur "Success line count" calculé comme ça : COUNT_PROCESSED
va devenir
COUNT_PROCESSED + COUNT_IGNORED

Es-tu OK ?
Merci de ton retour pour modification immédiate !

Cdlt,
dalila.
Commentaire de Frédéric Nahum [ 18/sept./09 17:57 ]
Je dirais plus :

L'indicateur "Rejected line count" calculé comme ça :
COUNT_ERRORS
va devenir
COUNT_ERRORS
Donc ca ne change pas

L'indicateur "Success line count" calculé comme ça : COUNT_PROCESSED
va devenir
COUNT_PROCESSED + COUNT_IGNORED


Commentaire de Dalila Belkebir [ 25/sept./09 15:56 ]
Bonjour Frédéric,

La demande a été livrée, peux-tu stp nous la valider pour clôture du JIRA ?

Merci.

Cdlt,
dalila.
Commentaire de Frédéric Nahum [ 25/sept./09 17:56 ]
oui c'est nikel




OP de collecte 2010 - import de contacts (CAT-3032)

[CAT-3256] Problème avec l'import de contact Création: 02/nov./10 15:16  Mise à jour: 05/nov./10 14:54  Résolue: 05/nov./10 14:54

Etat: Résolu
Projet: Paramétrage - Non Import
Composants: Import de contacts Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sub-bug Priorité: Bloquant
Rapporteur: Carole Boucheny Attribution: Carole Boucheny
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Dépendance
est bloqué par EXP-5188 Mise à jour des contacts créés avec l... Résolu
Similaire
similaire à APP-31579 Le batch d'import de contacts abonne ... Bloqué
Pays:
FRA - France

 Description   
Dans nos scripts les colonnes correspondants aux abonnements à VMC et AVAL sont nulles. Or le batch d'import de contact semble mal gérer ce cas.

Il faut donc :
-> Extraire tous les contacts à désabonner de ces newletters et l'envoyer au BI
-> Demander au DBA de désabonner ces contacts de ces newletters
-> Modifier tous les scripts d'import de contact pour que cette colonne soit toujours à 0 et non nulle
-> Metter à jour les tables temporaires.

 Commentaires   
Commentaire de Carole Boucheny [ 02/nov./10 15:43 ]
Les tables temporaires ont toujours 0 dans les colonnes correspondant à l'abonnement aux newletters VMC et AVAL.
Commentaire de Carole Boucheny [ 02/nov./10 15:56 ]
Les scripts ont été modifié pour avoir 0 par défaut pour les colonnes concernées.
Les tables temporaires ont été mise à jour.
En ce qui concerne le désabonnement en prod, ceci ne pourra être fait qu'à partir de jeudi par Patrick.
Commentaire de Carole Boucheny [ 02/nov./10 16:09 ]
La correction a faire son dû au problème de ce jira : APP-31579 (mauvaise gestion du null par le batch d'import de contact).
Commentaire de Carole Boucheny [ 02/nov./10 17:25 ]
Le BI n'a finalement pas besoin de l'extract :

"En fait, nous ne faisons que transmettre les données de la base OLTP aux partenaires.
Corriger nous-même les données demanderait des développements coûteux et ne correspondrait plus à notre philosophie qui est de restituer les informations de la base de données du site.
Donc on attend la correction en Production.
Agathe"

Il faut donc attendre le retour de Patrick pour pouvoir résoudre ce problème. (Il revient jeudi)
Commentaire de Carole Boucheny [ 05/nov./10 14:52 ]
Les contacts qui avaient été abonné à AVAL et VMC ont été désabonné dans notre base.




[BIN-528] extraction du stock pro alphalibris Création: 15/déc./08 10:55  Mise à jour: 17/déc./08 15:38  Résolue: 15/déc./08 18:09

Etat: Fermé
Projet: Business Intelligence
Composants: Sales
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Bloquant
Rapporteur: Anne Korchia Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
bonjour
je n'arrive pas à faire une extraction de stock pour le pro alphalibris sur bi ça bloque, le parma ne peut le faire non plus pourriez vous m'aider?
Merci

 Commentaires   
Commentaire de Cyril Tanneau [ 15/déc./08 18:09 ]
Anne,

tu trouveras le fichier d'export de stock d'Alphalibris au format CSV dans le dossier suivant, sur W.

W:\agathe\Export_de_stock_alphalibris_081215

La requête était en effet très couteuse, le stock de ce vendeur étant relativement important.

Je te laisse revenir vers nous si tu as des questions.

Merci,

Cyril.

Commentaire de Anne Korchia [ 15/déc./08 18:12 ]
merci beaucoup !




[cob] META-TACHE Fermeture Epik (APP-25109)

[APP-25113] Arrêt des rapports B.I pour le cob Epik Création: 29/avr./09 19:11  Mise à jour: 02/sept./09 09:59  Echéance: 01/juil./09 00:00  Résolue: 06/août/09 10:20

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 52.0.0 (CTN-M)

Type: Sous-tâche Priorité: Majeur
Rapporteur: Fabrice Feugas Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Description   
Le cob Epik sera inactif à partir du 01/07/2009.

Merci d'arrêter les rapports BI en même temps.

 Commentaires   
Commentaire de Agathe Remy [ 30/avr./09 11:40 ]
Arrêt du listing mensuel des nouveaux membres le 03/07
Arrêt du reporting hebdo le 06/07

Agathe
Commentaire de Cyril Tanneau [ 29/juin/09 12:42 ]
Les rapports de cobranding EPIK ont bien été arrêtés à la date spécifiée dans le JIRA,

Merci,

Cyril Tanneau
Commentaire de Cyril Tanneau [ 29/juin/09 12:48 ]
Erreur de ma part,

les rapports de cobrandings EPIK seront arrêtés Respectivement Vendredi prochain pour le listing mensuel et Lundi prochain pour le reporting hebdomadaire.

Merci,

Cyril Tanneau
Commentaire de Fabrice Feugas [ 29/juin/09 15:31 ]
Ouf, ok merci.
Commentaire de Christophe Garcia [ 29/juin/09 15:42 ]
MDPLVC




[cob] META-TACHE Fermeture Dauphiné Libéré et CamifOccasion (APP-25678)

[APP-25682] Arrêt des rapports B.I pour le cob Dauphiné Libéré et CamifOccasion Création: 19/juin/09 14:31  Mise à jour: 01/oct./09 11:28  Résolue: 28/sept./09 10:38

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 53.0.4

Type: Sous-tâche Priorité: Majeur
Rapporteur: Fabrice Feugas Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** A PLANIFIER ***

 Description   
Le cob Dauphiné Libéré et CamifOccasion seront inactifs à partir du 15/09/2009.

Merci d'arrêter les rapports BI en même temps.




[cob] META-TACHE Fermeture LeProgrès (APP-28357)

[APP-28361] Arrêt des rapports B.I pour le cob LeProgrès Création: 18/févr./10 17:49  Mise à jour: 15/avr./10 17:15  Résolue: 29/mars/10 12:02

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 67.0.0 (CTN-Q)

Type: Sous-tâche Priorité: Majeur
Rapporteur: Fabrice Feugas Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Description   
Le cob LeProgrès sera inactif à partir du 15/03/2010.

Merci d'arrêter les rapports BI en même temps.

 Commentaires   
Commentaire de Fabrice Feugas [ 18/févr./10 18:08 ]
Reporting hebdos et nouveaux inscrits.
Commentaire de Fabrice Feugas [ 29/mars/10 12:02 ]
Déjà fait depuis un moment :)




[CAT-2995] [Flux comparateur] Lister les flux existants Création: 11/août/10 17:52  Mise à jour: 23/août/10 11:06  Résolue: 23/août/10 11:06

Etat: Résolu
Projet: Paramétrage - Non Import
Composants: Flux Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Carole Boucheny Attribution: Carole Boucheny
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Text File flux_http.txt    
Pays:
ALL - Tous

 Description   
Voici la demande de Thierry :

_ Lister les urls des flux
_ Lister les flux accessibles par d'autres biais

 Commentaires   
Commentaire de Carole Boucheny [ 23/août/10 10:46 ]
Ci-joint la liste des flux disponibles en http
Commentaire de Carole Boucheny [ 23/août/10 10:52 ]
Il ne s'agit que des flux pour la France
Commentaire de Thierry Leforestier [ 23/août/10 11:06 ]
Merci Carole, c'est suffisant pour le moment :)




[APP-501] Generation et envoie automatique 2 fois par semaine a mettre en place... Création: 14/juin/01 10:21  Mise à jour: 25/juin/07 18:21  Résolue: 25/juin/07 18:21

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): old
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Justin Ziegler Attribution: Jean-François Mach
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
... meme date que les autres rapport bi hebdo.
Destinataires : nath, olivier.mathiot, jz




[APP-30959] [Coupon rendu monnaie] Modification du secret name associé au coupon avoir Création: 13/sept./10 12:19  Mise à jour: 17/sept./10 11:11  Résolue: 13/sept./10 16:59

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 77.0.0 (TX-P)
Version(s) corrigée(s): 77.0.0 (TX-P)

Type: Bogue Priorité: Majeur
Rapporteur: Thomas Landru Attribution: Yann Danot
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Dev
Projets PM: Paiement - Coupon et rendu monnaie
Navigateur: Tous

 Description   
Modifier le secret name du coupon associé à l'utilisateur pour faciliter l'exploitation des résultats en BI : SECRETNAME_AVOIR_ID




[IMP-8088] C'est la fin des SOLDES > mettre à jour le titre des annonces asap car potentiel problème avec la DGCCRF > MILO-78 Création: 17/févr./11 10:44  Mise à jour: 17/févr./11 16:17

Etat: Ouvert
Projet: Paramétrage - Import
Composants: Demande commerciale
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Isabelle Weisbecker Attribution: Dispatcher (Param-Import)
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Advert listing by login_milo-78_17.02.2011.csv    
Pays:
FRA - France
Login: MILO-78
Modèle: extraction BI
Séparateur: N/A
Type de traitement:
Mise à jour/création annonces avec mise à jour/création produits

 Description   
c'ets la fin des soldes, le pro n'a pas accès aux titres pour les modifier. pourriez-vous mettre à jour les annonces avec l'extraction BI ci-joint. merci.




[BIN-597] [tracking Keyade] analyse des purchase id Création: 23/juin/09 12:52  Mise à jour: 08/juil./09 19:10  Résolue: 08/juil./09 19:10

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Mathieu Richomme Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel LS - Paniers Keyade.xls    
Pays:
FRA - France

 Description   
Bonjour,

voici une liste de purchase id marqués LS en base chez nous (vérifié avec Swan)
ils sont présents dans la base Keyade mais pas dans mon rapport "LS - Paniers Keyade" (dossier Mathieu)
en PJ le rapport BI en question, sorti pour le 17/06, pour les 6 tracking group commençant par "LS-"

j'ai vérifié le rapport public "Purchase by purchase tracking 30 days", il me sort le même nombre de paniers que mon rapport perso (c'est le même rapport avec la colonne purchase id en plus)

d'avance merci pour votre aide sur le sujet, à votre dispo pour en rediscuter si ce n'est pas clair
Mathieu

72458402
72474445
72459005
72455405
72455732
72455817
72456211
72456234
72456252
72456334
72456343
72456448
72457172
72464751
72487778
72466098
72474631
72469344
72470366
72471930
72485736
72472573
72454754
72454725


 Commentaires   
Commentaire de Mathieu Richomme [ 08/juil./09 18:53 ]
vu avec Agathe, concernant les 24 paniers du 17/06 remontant chez Keyade et pas dans BI:
- pour 11 paniers, le jour de creation est différent du jour d'autorisation => normal qu'ils ne remontent pas dans le rapport (ex: créé le 16/06 à 23h55 et autorisé après minuit)
- pour 1 panier, la différence entre la date de creation et la date de depôt du cookie est > à 30 jours => bizarre qu'il remonte via le tag mais négligeable
- pour 12 paniers c'est lié à un problème déjà identifié et en cours de résolution => négligeable de toute manière vu les volumes

on est donc bon sur le tracking ;))

merci!
Mathieu
Commentaire de Mathieu Richomme [ 08/juil./09 18:56 ]
"remontant chez Keyade et pas dans le rapport Purchase by Purchase Tracking" pour être précis !
Commentaire de Agathe Remy [ 08/juil./09 19:10 ]
Merci Mathieu!




[APP-18288] DB Integ : Tables obsoletes Création: 18/oct./07 16:51  Mise à jour: 11/mars/10 10:20  Résolue: 10/mars/10 18:13

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 17.0.0
Version(s) corrigée(s): 63.0.3

Type: Tâche Priorité: Mineur
Rapporteur: Quentin de Chivré Attribution: Ayoub Benseghir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel obs_tab.xls     Microsoft Excel obs_tab.xls    
Pays:
FRA - France
Site: Integ
Projets PM: *** A PLANIFIER ***

 Description   
Les tables suivantes ne me paraissent pas utilisées (elles sont en Integ et donc probablement aussi en Prod)
=> on doit pouvoir faire du ménage (après vérification...)

administration :
  BACK_CATEGORY_TRANSLATION
  FEED_PRODUCT_URL

summary :
 MV_CAPABILITIES_TABLE

user :
 BACKUP_COUNTRY
 TEMP_LOGIN

purchase :
 CK_LOG

product :
 BACK_PRD_FRONT_CATEGORY
 BACK_PRD_FRONT_CLASSIFICATION
 BACK_PRD_BACK_CATEGORY
 APP8180
 OPTIMIZATION_DATE
 CK_LOG
 INDEX_REPORT
 XRES
 TEST_BI
 TMP_CAT
 VAT_TO_DELETE
 DYNAMO_NEW
 TEMP_ID
 TEMP_PRODUCT_URL
 SAV_DISPLAY_UNIT
 SAV_STACK
 SHOES_TO_MIGRATE



 Commentaires   
Commentaire de Quentin de Chivré [ 15/avr./08 14:08 ]
Nouvelle liste :

 

*** Product :

Tables à supprimer ?
  APP8180
  BACK_PRD_BACK_CATEGORY
  BACK_PRD_FRONT_CATEGORY
  BACK_PRD_FRONT_CLASSIFICATION
  SAV_DISPLAY_UNIT
  SAV_STACK
  SHOES_TO_MIGRATE
  TEMP_ID
  TEMP_PRODUCT_URL
  TEST_BI
  TMP_CAT
  VAT_TO_DELETE


Tables DBA ?
  DYNAMO_NEW
  CK_LOG
  XRES
  INDEX_REPORT
  OPTIMIZATION_DATE

*** Administration :
  BACK_CATEGORY_TRANSLATION
  HELP => Dev
  HLP_* => Dev

*** Purchase :
   CK_LOG

*** Summary :
  MV_CAPABILITIES_TABLE
  SEARCH_HISTORY => Dev
  SHI_PAGE_CODE => Dev

*** User :
  BACKUP_COUNTRY
  TEMP_LOGIN
  USR_EVENT_NEW

 

 
Commentaire de Quentin de Chivré [ 08/juil./08 11:29 ]
Quelles tables ont étés suppriméesfinalement ?
Toutes celles ci-dessus ? Certaines devaient plutot l'etre par le dev, des fonctionnalités risqueraient de ne plus marcher, voire meme le build pourrait etre cassé si on vire des tables de code référencéesr l'appli (je pense aux tables marquées => Dev dans mon commentaire précédent)
Commentaire de Ayoub Benseghir [ 08/juil./08 11:39 ]
Pour l'instant il n'y pas de tables supprimées. Certaines sont toujours utilisées et ne seront pas supprimées (ex: DYNAMO_NEW), d'autres ont été renommées en DEV et en INTEG (script en V25) en attendant un éventuel retour des devs ou autre et enfin une dizaine de tables sont monitorées en prod pour confirmer/infirmer leur non utilisation.
Commentaire de Quentin de Chivré [ 08/juil./08 12:40 ]
C'est possible d'avoir en PJ du Jira un fichier XL qui dit précisemment ce qu'on a fait sur chaque table ? Renommage / monitoring / conservation ?
Un renommage sur les tables qui m'inquietent (vois commentaire précedent) aura le même effet "plantage du build"
Commentaire de Ayoub Benseghir [ 09/juil./08 10:29 ]
Actions sur les tables obsolètes
Commentaire de Quentin de Chivré [ 09/juil./08 11:06 ]
Merci c'est clair.

Au final rien n'a été fait sur les tables suivantes :
  HELP => Dev
  HLP_* => Dev

  SEARCH_HISTORY => Dev
  SHI_PAGE_CODE => Dev

Ca me parait bien car le mieux est que le Dev supprime ces tables en même temps que le code appli associé.

Ceci dit je me suis trompé sur les histoires de build, on fait tout sur la base de Dev et plus sur la base d'integ comme par le passé, donc les pbs seraient ** eventuellement ** apparus au démarrage de JBoss, pas au build.
Commentaire de Quentin de Chivré [ 09/juil./08 11:07 ]
Ceci dit, je trouve mieux de réouvrir le Jira jusqu'a ce qu'on ai les conclusions et qu'on décide de rééllement supprimer les tables ou pas.
Non ?
Commentaire de Ayoub Benseghir [ 24/juil./08 10:40 ]
Les tables qui étaient en auditées sont maintenant renomées en dev en en integ.
Commentaire de Ayoub Benseghir [ 10/oct./08 11:38 ]
Misa a jour
Commentaire de Ayoub Benseghir [ 10/oct./08 11:41 ]
Les tables qui ont été renommées sont maintenant supprimées en dev et en integ. cf obs_tab.xls pour les détails
Commentaire de Ayoub Benseghir [ 10/mars/10 11:39 ]
c'est fait
Commentaire de Christophe Garcia [ 10/mars/10 18:11 ]
MDPLVC




[APP-27767] Problème sur la pose des Tags d'un partenaire en affiliation: Effiliation Création: 23/déc./09 17:42  Mise à jour: 28/janv./10 11:43  Résolue: 19/janv./10 09:15

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 61.0.0 (CTN-O)

Type: Bogue Priorité: Bloquant
Rapporteur: Jonathan Gorges Attribution: Swan Desportes
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Exemple de panier remontant sur la plateforme sans last tracking 30 jours sur la journée du 10 decembre 2009.xls    
Liens des demandes:
Similaire
similaire à APP-27869 Différence entre les trackings qui re... Fermé
Pays:
FRA - France
Projets PM: *** CHASSE ***

 Description   
Bonjour,

Nous venons de déceler un problème majeur en affiliation.

Constat:
Notre plateforme d'affiliation "Effiliation" remonte beaucoup plus de paniers autorisés que nos reporting BI.

Pourquoi?
Après avoir testé plusieurs paniers dans le back office, il apparaît que la plateforme Effiliation remonte des paniers qui ont plus de 30 jours.
Il s'agit par exemple de 550 paniers en trop pour la date du 10/12/2009

Exemple:
Panier n°: 79229229
Création du panier: 10/12/2009
Tracking de session : Affiliationx-Netavenir-bannieres (905640) 06/10/2009-03:33 - Indirect
 
Les affiliés voient donc beaucoup de ventes remonter sur leur extranet que nous ne devons pas payer.

Pourriez-vous nous aider à vérifier si tout fonctionne bien côté PriceMinister svp? Nous faisons nos recherches côté plateforme d'Effiliation.

Merci d'avance pour votre aide.

JG

 Commentaires   
Commentaire de Jonathan Gorges [ 23/déc./09 17:43 ]
En pièce jointe un extract des paniers qui posent problème.
Commentaire de Jonathan Gorges [ 23/déc./09 17:49 ]
Bonjour,

Nous venons de voir avec la plateforme et ils nous assurent qu'aucune modification n'a été faite (concernant les cookies par exemple), durant cette période.

Le problème semble ce trouver chez nous.

Merci d'avance pour votre aide à ce sujet.

Jonathan.
Commentaire de Marion Anfreville [ 05/janv./10 13:05 ]
Est-ce que le problème est toujours d'actualité ?
Commentaire de Jonathan Gorges [ 05/janv./10 14:01 ]
Hello,

Effectivement, ce problème est toujours d'actualité.

Pour ma part, je travaille étroitement avec la plateforme d'affiliation pour voir si l'on peut déceler le moindre problème.

Avez-vous constaté qqchose de votre côté?

Merci
Commentaire de Olga Costa [ 05/janv./10 14:21 ]
Jonathan,
tu parles des tag buy, first buy ou première mise en vente?
De notre coté nous pouvons faire un test pour vérifier si il s'agit d'un tracking moins de 30 jours. Nous faisons déjà ce test pour les tags de première mise en vente. Mais il n'a jamais été fait pour les buy et first buy quel que soit la plateforme (zanoxx, affilinet etc..). Si le pb vient du fait que nous ne faisons pas ce test alors ce pb doit exister pour les autres plateformes aussi.
Commentaire de Jonathan Gorges [ 05/janv./10 14:35 ]
Hello,

Merci pour ce retour. Le problème constaté concerne aujourd'hui le tracking buy.

Effectivement, pourriez-vous faire un test comme précisé ci-dessus?

Merci d'avance
Commentaire de Swan Desportes [ 05/janv./10 14:41 ]
[CAJ2010Q1CTN]

Hello Jonathan,

Nous ne pouvons malheureusement rien y faire. A moins d'organiser un développement en urgence...
Le fonctionnement est tout à fait normal. La limitation 30 jours est une notion BI. Elle n'a pas d'existence côté site PM. Il est donc tout à fait possible de remonter des tags Effiliation à plus de 30 jours.
A mon avis, les siteunders devaient en masquer une bonne partie. C'est pour cela que l'on en voit beaucoup maintenant.

Est ce qu'il y a moyen de demander à Effiliation de ne pas tenir compte de ces paniers + de 30 jours ?

Merci

Swan
Commentaire de Jonathan Gorges [ 06/janv./10 08:56 ]
Hello Swan,

Merci pour ce commentaire et tes recherches.

Effectivement, nous allons demander à Effiliation ne pas tenir compte de ces paniers.

Merci.

JG
Commentaire de Christophe Garcia [ 06/janv./10 15:11 ]
MDPLVC




[BIN-210] Correction rapport BO "payment by purchase" Création: 26/oct./06 17:18  Mise à jour: 14/sept./07 17:31  Résolue: 15/déc./06 18:44

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Critique
Rapporteur: Philippe Favrot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Encaissement journée du 30 sept 06.xls     Microsoft Excel Encaissement journée du 30 sept 06.xls    
Pays:
ALL - Tous

 Description   
mon mail du 25/10 reproduit ci-après :

Je me rends compte que je n'avais pas joint le fichier...
depuis, j'ai travaillé sur une journée plus récente (30 septembre) incluant des transactions payées via 1¿.com.

Sauf erreur de ma part, le rapport « payment by purchase » inclus les transactions financées par 1¿.com ; peux tu vérifier car tu m'avais indiqué le contraire. Il faudrait que ces transactions soient clairement identifiées dans ce rapport ; par exemple par une mention spécifique dans la colonne « card type » qui est actuellement vierge de toute mention lorsqu'il s'agit d'un paiement via 1¿.com.

Par ailleurs, tu constateras donc des écarts au niveau du « Authorized GMS » ; peut être un lien avec mon mail du 20 septembre.
Merci de ton retour
Philippe
--------------------------------------------------------------------------------
De : Philippe FAVROT [mailto:philippe.favrot@priceminister.com]
Envoyé : lundi 23 octobre 2006 11:28
À : 'Agathe Remy'; 'pierre.krings@priceminister.com'
Cc : 'justin.ziegler@priceminister.com'
Objet : RE: BI Finance

Agathe,

« Payment by purchase » : suite à notre réunion de mercredi, j'ai donc procédé à la réconciliation de la journée du 30 juin 2006 entre BO et Titan ; voir le fichier en pièce attachée.
On a donc des écarts sur la partie « Authorized GMS ».
Par ailleurs, pour boucler cette partie « suivi des encaissements », il faut un rapport similaire pour le type de paiement 1euros.com.
Merci
Philippe

 Commentaires   
Commentaire de Agathe Remy [ 31/oct./06 10:55 ]
Bonjour Philippe,

J'ai ajouté la colonne payment type dans le rapport payment by purchase afin que tu puissent identifier les paiements 1euros.

Cela te convient-il?

Merci:-)

Agathe
Commentaire de Philippe Favrot [ 31/oct./06 19:46 ]
Bonsoir Agathe,
merci pour cette modif.
mais je suis un peu troublé car le rapport ne donne plus le même résultat qu'avant ta modification (sur la base de la journée du 30 septembre) ; voir le fichier attaché.
Par ailleurs, peux tu mettre en place une invite sur le "card type" et une autre sur le "payment type".
Merci
Philippe
Commentaire de Agathe Remy [ 02/nov./06 14:23 ]
Bonjour Philippe,

La différence de résultat était du au fait qu'en rajoutant le payment type, j'ai exclu toutes les transactions sans type de paiement (payées uniquement par PMV).
J'ai corrigé cette erreur et maintenant, tu dois trouver les mêmes résultats que précédemment (j'ai vérfié).

D'autre part, j'ai ajouté les invites sur card type et payment type.
Si tu veux ne pas sélectionner de valeur particulière, il faut saisir % à la main dans l'invite.

Cordialement,
Agathe
Commentaire de Philippe Favrot [ 03/nov./06 11:44 ]
Bonjour Agathe,
merci ; effectivement la requête donne à présent le même résultat qu'initialement.
Reste donc àtraiter l'écart sur l'indicateur "Authorized GMS".
Philippe
Commentaire de Agathe Remy [ 24/nov./06 14:33 ]
Bonjour Agathe,

Serait il possible d'intégrer dans le rapport payment by purchase les informations suivantes :

            N° transaction Sips

            N° autorisation Sips

Merci

Philippe

Commentaire de Philippe Favrot [ 04/déc./06 10:31 ]
Agathe,
suite à notre réunion du 21 nov.
Concernant les écarts mis en évidence au niveau de l'authorized GMS, merci d'ajuster sur le rapport "purchase summary" ==> les transactions isolées dans l'onglet 5 ne doivent donc pas être reprises dans le rapport "payment by purchase".
Pour les autres écarts (cf onglet 4), c'est à toi d'investiguer.
Merci
Philippe
Commentaire de Agathe Remy [ 14/déc./06 18:55 ]
Philippe,

Si, comme tu le dis, les transactions isolées dans l'onglet 5 ne doivent pas apparaître dans le rapport "payment by purchase", cela signifie que nous excluons de ce rapports :
- les paniers passés en CONFIRMATION_DENIED
- les paniers de type négociation ayant été annulés
Peux-tu me le confimer?

Doit-on aussi exclure les paniers auto (pack vendeur, garanties) qui ne sont pas dans le rapport "Purchase summary by month"?

Merci:-)

Agathe
Commentaire de Agathe Remy [ 14/déc./06 19:14 ]
Voici le résultat de mon investigation sur les écarts de l'onglet 4 :

Dans BI : Authorized GMS = Authorized payment amount + Authorized coupon amount
Dans Titan : Authorized GMS = Authorized payment amount + Captured coupon amount

Cette différence de formule explique ces écarts.
Il me semble donc que le rapport BI est plus cohérent que celui de Titan, mais, sachant que dans le rapport "Purchase summary by month", le champ Authorized GMS = Authorized payment amount + Captured coupon amount (comme dans Titan), à toi de juger !

Merci:-)

Agathe
Commentaire de Agathe Remy [ 14/déc./06 19:25 ]
Les colonnes N° transaction Sips et N° autorisation Sips ont été ajoutées au rapport "Payment by purchase".

J'ai supposé que le N° transaction Sips correspondait au champ "Authorization number request" et le N° autorisation Sips au champ "Authorization number response".
Peux-tu me dire si cela te parait correct?

Merci:-)

Agathe

Commentaire de Philippe Favrot [ 15/déc./06 13:47 ]
Bonjour Agathe,

mes commentaires à tes questions de ces derniers jours sur ce rapport :

1 - Si, comme tu le dis, les transactions isolées dans l'onglet 5 ne doivent pas apparaître dans le rapport "payment by purchase", cela signifie que nous excluons de ce rapports :
- les paniers passés en CONFIRMATION_DENIED
- les paniers de type négociation ayant été annulés
Peux-tu me le confimer?

oui je confirme ; l'objectif est d'aligner la façon de déterminer le VA autorisé entre les différents rapports. D'ailleurs, sauf erreur de ma part tu as déjà fait cette modification ?

2 - Doit-on aussi exclure les paniers auto (pack vendeur, garanties) qui ne sont pas dans le rapport "Purchase summary by month"?

effectivement les paniers auto ne sont pas repris dans le rapport "purchase summary" ; néanmoins il est impératif de les maintenir dans le rapport "payment by purchase" car ce rapport est avant tout destiné à suivre canal / canal l'encaissement des achats (or en matière d'encaissement, les paniers auto suivent le même traitement que les paniers classiques achat-vente).

3 - Voici le résultat de mon investigation sur les écarts de l'onglet 4 :

Dans BI : Authorized GMS = Authorized payment amount + Authorized coupon amount
Dans Titan : Authorized GMS = Authorized payment amount + Captured coupon amount

Cette différence de formule explique ces écarts.
Il me semble donc que le rapport BI est plus cohérent que celui de Titan, mais, sachant que dans le rapport "Purchase summary by month", le champ Authorized GMS = Authorized payment amount + Captured coupon amount (comme dans Titan), à toi de juger !

On est donc d'accord que le VA autorisé tel que déterminé dans le rapport BI "payment by purchase" est celui qui est exact. Néanmoins je n'ai pas envie qu'on retouche pour l'instant au rapport "purchase summary by month" donc je suggère de modifier "payment by purchase" (le VA autorisé est un indicateur de gestion et pas une donnée qui est comptabilisé ; donc cette erreur est supportable d'autant plus qu'ele porte sur des montants faibles).

4 - Les colonnes N° transaction Sips et N° autorisation Sips ont été ajoutées au rapport "Payment by purchase".

J'ai supposé que le N° transaction Sips correspondait au champ "Authorization number request" et le N° autorisation Sips au champ "Authorization number response".
Peux-tu me dire si cela te parait correct?

J'ai pris le purchase ID : 38996672
ds le Back Office : on a : N° transaction Sips = 186 136
                                             N° autor Sips = 929 829
ds ton rapport : on a : Sips transaction number = 186 136
                                        Sips autorisation number = 926829
Ca me semble être ok

Reste doncd le point 4 à modifier et on devrait être bon pour ce rapport
Merci
Philippe

Commentaire de Agathe Remy [ 15/déc./06 18:44 ]
Le VA autorisé a été modifié dans la rapport Payment by purchases.

Cordialement,
Agathe
Commentaire de Philippe Favrot [ 19/déc./06 09:56 ]
Bonjour,
sur la base de la journée du 30 septembre ça fonctionne maintenant.
Donc sous réserve d'anomalies que mettrait en évidence une "utilisation plus intensive" du rapport c'est ok pour moi.
Tu peux fermer le Jira.
Philippe




[EXP-666] Déploiement outil de supervision MINITOR sur LATONE Création: 22/déc./05 16:49  Mise à jour: 25/juin/07 18:55  Résolue: 23/déc./05 10:52

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Sébastien Tournay Attribution: Xiaoming Du
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Xiaoming,

On vient de déployer en PROD le serveur LATONE. C'est un serveur que nous allons utiliser pour la bdd BI. Pourrais-tu lui installer MINITOR avec un profil BDD. On pourra le faire évoluer ensuite pour des besoins spécifiques BI.

Il faut aussi penser à le mettre dans notre boucle de ping pour détecter les arrêt et reboot.

 Commentaires   
Commentaire de Xiaoming Du [ 23/déc./05 10:52 ]
http://intra.priceminister.com/qvpm.html

Latone arrive.




[DEC-351] Nombre membres, acheteurs, abonnés news depuis 2004 mois par mois Création: 17/mai/06 10:13  Mise à jour: 14/sept./07 14:40  Echéance: 24/mai/06 00:00  Résolue: 27/juin/06 16:42

Etat: Fermé
Projet: Reporting
Composants: Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Odile Szabo Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: 4 heures
Temps consacré: Non spécifié
Estimation originale: 4 heures


 Description   
samir m'a dit qu'il était possible de sortir sur BI le nombre de membre , d'acheteurs, d'abonnés à une news (et pas offres partenaires) mois par mois de puis 2004.
merci
Odile

 Commentaires   
Commentaire de Samir Beghdadi [ 22/mai/06 12:35 ]
Slt,
Voila je te réassigne le jira de la demande d'Odile pour le nombre de membre et d'acheteurs mois par mois de puis 2004, le rapport se trouve dans le dossier Purchase/V1.1/User-Bayer odile, concernant le nombre d'abonnés à une news (et pas offres partenaires) mois par mois de puis 2004, le rapport a été déjà généré par Cyrille.

Merci.




[EXP-2979] "preview.priceminister.es" accès de chez moi Création: 13/nov./06 09:36  Mise à jour: 25/juin/07 18:59  Résolue: 15/nov./06 11:08

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Yassine Mouhammadou Attribution: Patrice Boulanger
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne

 Description   
Par curiosité, j'ai essayé de me connecter sur http://preview.priceminister.es/ de chez moi ce WE, et j'ai eu l'accès (par le biais de la saisie de log et mdp)

 Commentaires   
Commentaire de Antoine Koener [ 15/nov./06 11:08 ]

Merci, d'avoir testé. Cela veut dire que ca marche même depuis chez toi.

Pour bloquer j'attends le calendrier.





[DEC-639]  [Référencement] : Nouvel export Widgets Création: 19/nov./08 16:54  Mise à jour: 07/avr./09 14:49  Résolue: 20/nov./08 15:04

Etat: Fermé
Projet: Reporting
Composants: Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Thierry Leforestier Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel URL_widgets_FR_ES_20081120.xls    
Pays:
FRA - France

 Description   
Nous avons besoin d'un nouvel export des données du BI pour les widgets afin d'étudier l'impact éventuel des liens synergie en France.

Merci d'avance !

 Commentaires   
Commentaire de Agathe Remy [ 20/nov./08 15:04 ]
Thierry,
Tu trouveras ci-joint le nouvel export des widgets boutique et parrainage FR et ES.
Le fichier est également présent dans le répertoire :
V:\Reporting\Maintenance\Developpement\Url widgets

Agathe




[APP-22653] [UK] Ajouter promo frais de port gratuit sur toutes les pages de nav Création: 21/oct./08 14:54  Mise à jour: 22/déc./08 11:39  Résolue: 16/déc./08 10:53

Etat: Fermé
Projet: Application PriceMinister
Composants: Promo
Affecte la/les version(s): 31.0.3, 35.0.0 (CTN-H)
Version(s) corrigée(s): 37.0.0 (TX-D)

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Charles Decaux Attribution: Rémi Virlouvet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File free-delivery-459x43-01.swf    
Liens des demandes:
Duplicate
Pays:
GBR - Royaume Uni
WishList: Marketing
Classif2: contenu
Classif FONC: comarket
Projets PM archivés: UK - Adaptations fonctionnelles

 Description   
Lors de la sortie du site UK, on voudrait mettre en avant les frais de port à 0 par le biais d'une promo ressemblante à ce qu'on a fait pour MVNO sur la France.

 Commentaires   
Commentaire de Charles Decaux [ 27/oct./08 14:08 ]
Le mieux serait de se baser sur le travail effectué par Corinne sur la home page sur les frais de port gratuit et de se servir de ce travail pour le décliner en tant que promo sur les autres pages du site.

Voir :

T:\00_Maquettage\00_Projets\PM_UK\HP\home_uk_changement_wording.png
Commentaire de Jérôme Viviès [ 19/nov./08 09:03 ]
??? Je pense qu'il va falloir nous fournir une créa précise.
Merci de te renseigner auprès de Benjamin pour connaitre les modalités de mise en place des cette promo et de repréciser ta demande, stp.
Commentaire de Charles Decaux [ 19/nov./08 09:41 ]
Hello, vu avec Gafour : il se cale sur votre planning pour vous livrer la créa. Je lui ai indiqué que vous travaillerez dessus en S49
J'affecte donc le JIRA à Gafour.
Merci
Commentaire de Gafour Abdoul [ 19/nov./08 18:42 ]
Charles, vu que ça sera fait par le webdesign market, je le réattribue au Param.
Commentaire de Charles Decaux [ 19/nov./08 18:57 ]
Ok très bien, la créa sera livrée le 26 novembre.

Merci
Commentaire de Ariane Baldinger [ 15/déc./08 15:43 ]
Charles,
On a besoin de précision :

- Le paramétrage doit se faire sur le Location_alias = FILTER_NAVIGATION ?
- Position Body inside?
- Il faut mettre la bannière sur toutes les familles produits ?
Commentaire de Charles Decaux [ 15/déc./08 17:08 ]
La réponse est oui à toutes les questions !
Merci Ariane :-)
Commentaire de Rémi Virlouvet [ 15/déc./08 18:01 ]
Cette bannière a été refaite en v2 suite à des soucis en HomePage non? je prends la v2 ou c'est autre chose?
Commentaire de Charles Decaux [ 15/déc./08 18:05 ]
oui il faut prendre la deuxième version qui corrige un pb d'alignement du texte

merci
Commentaire de Rémi Virlouvet [ 15/déc./08 18:26 ]
Olga, testage now :)
Commentaire de Rémi Virlouvet [ 15/déc./08 18:27 ]
Please ^^
Commentaire de Rémi Virlouvet [ 15/déc./08 18:31 ]
Charles,

tu peux tester en dev.
Commentaire de Olga Costa [ 15/déc./08 18:33 ]
ok pour moi
Commentaire de Charles Decaux [ 15/déc./08 19:04 ]
Ok c'est bon, merci
Commentaire de Rémi Virlouvet [ 16/déc./08 10:10 ]
/promotions/Promotions/GB/Promos/Free UK Delivery




[APP-21182] [MODULE VENDEUR] Etape 1 : Pouvoir sélectionner un widget en cliquant sur l'image Création: 10/juil./08 14:07  Mise à jour: 08/sept./08 10:30  Résolue: 16/juil./08 15:05

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 25.0.0 (CTN-D)
Version(s) corrigée(s): 28.0.0 (CTN-F)

Type: Amélioration Priorité: Mineur
Rapporteur: Cédric Goldovsky Attribution: Clement Balay
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
ALL - Tous
Site: Integ
Projets PM archivés: MKT communautaire (Label Vendeur)

 Description   
Etape 1 : Il pourrait être user friendly que le choix d'un widget (boutique ou catégorie) ne se fasse pas exclusivement par le biais des radio boutons et que les images soient cliquables.

 Commentaires   
Commentaire de Clement Balay [ 16/juil./08 15:05 ]
cvs ci src/com/babelstore/user/front/SellerModuleView.jsp
dos2unix: converting file SellerModuleView.jsp to UNIX format ...
Checking in src/com/babelstore/user/front/SellerModuleView.jsp;
/home/cvs/dev/source/src/com/babelstore/user/front/SellerModuleView.jsp,v <-- SellerModuleView.jsp
new revision: 1.11.4.1; previous revision: 1.11
done




[cob] META-TACHE Fermeture cobs Mobilesachat, Free Surf, France Mobile, Midi Libre, Nice Matin (APP-25098)

[APP-25102] Arrêt des rapports B.I pour les cobs Mobilesachat, Free Surf, France Mobile, Midi Libre, Nice Matin Création: 29/avr./09 18:52  Mise à jour: 02/sept./09 10:00  Echéance: 07/mai/09 00:00  Résolue: 01/juil./09 12:25

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 52.0.0 (CTN-M)

Type: Sous-tâche Priorité: Majeur
Rapporteur: Fabrice Feugas Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Description   
Les cobs Mobilesachat, Free Surf, France Mobile, Midi Libre, Nice Matin seront inactifs à partir du 07/05/2009.

Merci d'arrêter les rapports BI en même temps.

 Commentaires   
Commentaire de Cyril Tanneau [ 29/juin/09 12:40 ]
Les rapports de cobrandings ont bien été arrêtés à la date spécifiée dans le Jira.

merci,

Cyril Tanneau
Commentaire de Christophe Garcia [ 29/juin/09 15:42 ]
MDPLVC
Commentaire de Cyril Tanneau [ 01/juil./09 12:25 ]
Les rapports de cobrandings ont bien été arrêtés à la date spécifiée dans le Jira.

merci,

Cyril Tanneau




[APP-32140] PEC : Suite au APP-32075, rattraper les comptes concernés... Création: 07/déc./10 19:07  Mise à jour: 07/déc./10 19:08

Etat: Ouvert
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Emeric Teil Attribution: Arnaud Forgues
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à APP-32075 [PEC] : Fusion inscriptione et adress... Fermé
Pays:
ALL - Tous
Projets PM: *** CHASSE ***

 Description   
Comme vu ensemble, il faudrait essayer de rattraper l'historique, en se basant sur l'évènement de création de compte contact = Purchase et en changeant leur évènement de migration ?

NB : penser à voir le BI la dessus...




[BIN-562] [Cobranding] : Membres Lycos Provence : réintégrer les données dans le flux PN_DATA Création: 27/févr./09 09:39  Mise à jour: 03/mars/09 14:10  Résolue: 03/mars/09 14:10

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Ghislain Gridel Attribution: Florian Ambrosi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Les partenariats Lycos et La provence ont pris fin officiellement le 15/02/2009. Un email a été envoyé le 14/02 à tous les comptes pour leur dire qu'ils peuvent continuer à acheter sur PM
L'équipe BI a déjà arrêté les rapports BI hebdo et mensuel le 16/02.
MM les a déjà intégrés dans sa base CRM.

Il reste à réintégrer les cobrandés --> réintégrer les données dans le flux PN_DATA : action BI, prochain envoi mensuel le 02/03. Sinon le 02/04.
(validation juridique ok)
Merci






[EXP-2638] Passage massif de comptes en 1 Création: 13/sept./06 15:08  Mise à jour: 04/déc./07 11:38  Résolue: 04/déc./07 11:38

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Sébastien Mantanus Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: GZip Archive tovalidate.csv.gz     File upd_correctif_reliability.sql     File upd_return_reliability.sql    
Liens des demandes:
Similaire
similaire à EXP-227 passage automatique des comptes en va... Résolu
Pays:
FRA - France

 Description   
Comme vu avec Edouard, nous allons procéder à un passage massif de comptes en 1, les conditions cont les mêmes que pour le précédent passage avec des assouplissements, soit :

- compte en 0
- compensation ok
- connexion ok
- PMV non bloqué
- email ok

- + de 50 ¿ achetés sur le compte
- compte vieux de plus de 4 mois

Merci




 Commentaires   
Commentaire de Antoine Koener [ 18/sept./06 09:19 ]
Je te l'assigne car je ne sais pas quoi faire de ce JIRA.
Commentaire de Patrice Boulanger [ 20/sept./06 11:22 ]
Cette demande devient urgente. Edouard, merci de revenir vers moi pour qu'on voit ça ensemble aujourd'hui.
Commentaire de Edouard Laurent [ 20/sept./06 14:56 ]
La requete va etre effectue par l'equipe decisionnelle
Il faut envoyer a sebastien la liste des comptes qu'il va faire valider par PKM
Ensuite je m'occuperais de faire l'update des comptes en prod

Merci !
Commentaire de Agathe Remy [ 20/oct./06 16:50 ]
SELECT
  USER_ACCOUNT.USER_ACCOUNT_ID,
  USER_ACCOUNT.LOGIN
FROM
  USER_ACCOUNT,
   PURCHASE,
  (SELECT DISTINCT BUYER_ACCOUNT_ID, MIN(AUTHORIZATION_DATE) AS FIRST_PURCHASE_DATE
    FROM PURCHASE
    WHERE PCH_STATUS_CODE NOT IN (10,20)
    GROUP BY BUYER_ACCOUNT_ID
    HAVING MIN(TO_CHAR(AUTHORIZATION_DATE,'YYYY/MM')) >= '2006-05'
   ) FIRST_PURCHASE
WHERE USER_ACCOUNT.USER_ACCOUNT_ID=PURCHASE.BUYER_ACCOUNT_ID AND
                PURCHASE.BUYER_ACCOUNT_ID=FIRST_PURCHASE.BUYER_ACCOUNT_ID AND
                USER_ACCOUNT.GRANT_EMAIL = 1 AND -- email OK
                USER_ACCOUNT.GRANT_LOGIN = 1 AND -- connexion OK
                NVL(USER_ACCOUNT.IS_TO_VALIDATE, 0) = 0 AND -- compte en 0
               USER_ACCOUNT.WLT_STATUS_CODE IN ( 10, 20 ) -- PMV non bloqué
GROUP BY USER_ACCOUNT.USER_ACCOUNT_ID,
                      USER_ACCOUNT.LOGIN
HAVING SUM(toEuro2(NVL(PURCHASE.CAPTURE_CARD_AMOUNT,0) + NVL(PURCHASE.CAPTURE_OPERATION_AMOUNT,0) + NVL(PURCHASE.CAPTURE_COUPON_AMOUNT, 0), PURCHASE.CURRENCY_ID)) >= 50
Commentaire de Edouard Laurent [ 20/oct./06 17:22 ]
Je dois faire quelquechose ?
Commentaire de Edouard Laurent [ 26/oct./06 16:34 ]
Je ferme ce JIRA ? ou il y a quelquechose a faire ? merci
Commentaire de Sébastien Mantanus [ 26/oct./06 16:48 ]
Ben il faudrait juste passer ces comptes en 1 et fermer le jira quand c'est fait; je reste à ta dispo si tu as besoin de plus d'infos
Commentaire de Sébastien Mantanus [ 27/oct./06 14:04 ]
Le nombre de comptes est de 110 799 comptes.

Je préfère qu'on attende le 8 novembre, date à laquelle Steven reviens pour le faire.
Commentaire de Edouard Laurent [ 27/oct./06 14:11 ]
Ok c'est note merci
Commentaire de Antoine Koener [ 16/nov./06 09:30 ]
PriceJira étant arrété lorsqu'Edouard a récupéré le traitement, je poste en mon nom le commentaire qu'il m'a envoyé:

apres avoir eu la validation de la part de Steven :

J'ai executé la requete suivante sur titan :

sqlplus babel_1/babel_1@GLOB.TITAN @ /data/priceminister/pmshare/exploit/edouard/bo_passage_massif_des_user_1.sql

qui crée la table "tovalidate" qui contient la liste des user_account_id a passer en validation AUTO 1

Ensuite j'ai mis a jour la base de prod grace au script suivant :

sqlplus babel_1/babel_1@GLOB.TITAN @ /data/priceminister/pmshare/exploit/edouard/passsage_1_OLTP.sql

Suite au passage de ce dernier script j'ai teste un compte au hasard : "amphoux" et je me suis rendu compte qu'il ne rentrait pas dans les cirteres

J'ai regarde plus en detail la requete de selection des donnees et je me suis rendu compte qu'il n'y avait pas de condition sur les compensations ce qui m'a semble bloquant

J'avais au prealable fait un test sur TITAN. donc les donnees de titan sont corompus aussi

Nous avons arrete avec Francois lelay l'alimentation de LATONE car c'est le seul endroit ou il y a encore les donnees correcte, nous avons verifie que le champ realibility etait bien mise a jour sur LATONE.

Actuellement il y a donc des comptes en validation automatique sur la production qui ne devrait pas l'etre


J'ai sauvegarde le contenu de la table "tovalidate" dans un dump "/data/priceminister/pmshare/exploit/edouard/tovalidate.dmp"
Commentaire de Patrice Boulanger [ 16/nov./06 11:47 ]
Agathe,

Peut-on extraire l'état des user_account_id avant le lancement du traitement d'Edouard afin de pouvoir les restaurer?

L'idéal serait de voir avec Patrick les données dont il a besoin ainsi que le format du fichier.

Merci.
Commentaire de Agathe Remy [ 16/nov./06 16:04 ]
Patrick,

Tu trouveras ci-joint le script de mise à jour des comptes qui n'auraient pas dus l'être.
Il y a 601 comptes à mettre à jour.

Cordialement,
Agathe
Commentaire de Agathe Remy [ 16/nov./06 16:06 ]
Pour info,

Le problème n'était pas celui qu'on croyait:-)
La condition de compensation est inutile dans la problématique "Validation Auto" qui ne concerne que les acheteurs.
En revanche, la condition compte à 0 avait mal été interprétée et traduite par la condition is_to_validate=0 au lieu de reliability=0.

Cordialement,
Agathe
Commentaire de Agathe Remy [ 16/nov./06 17:19 ]
Finalement nous faisons un retour arrière intégral!!!
Voici le nouveau script de mise à jour avec un peu plus de 135992 lignes.

Cordialement,
Agathe
Commentaire de Agathe Remy [ 16/nov./06 17:29 ]
Autre erreur : dans la condition de date, les formats ne sont pas les mêmes!!!
De plus, nous voulons les comptes ayant effectué leur premier achat avant cette date et non après.

Edouard,

Voici la requête corrigée :
 SELECT
  USER_ACCOUNT.USER_ACCOUNT_ID,
  USER_ACCOUNT.LOGIN
FROM
  USER_ACCOUNT,
   PURCHASE,
  (SELECT DISTINCT BUYER_ACCOUNT_ID, MIN(AUTHORIZATION_DATE) AS FIRST_PURCHASE_DATE
    FROM PURCHASE
    WHERE PCH_STATUS_CODE NOT IN (10,20)
    GROUP BY BUYER_ACCOUNT_ID
    HAVING MIN(AUTHORIZATION_DATE) < trunc(to_date('20060501','YYYYMMDD'))
   ) FIRST_PURCHASE
WHERE USER_ACCOUNT.USER_ACCOUNT_ID=PURCHASE.BUYER_ACCOUNT_ID AND
                PURCHASE.BUYER_ACCOUNT_ID=FIRST_PURCHASE.BUYER_ACCOUNT_ID AND
                USER_ACCOUNT.GRANT_EMAIL = 1 AND -- email OK
                USER_ACCOUNT.GRANT_LOGIN = 1 AND -- connexion OK
               USER_ACCOUNT.RELIABILITY = 0 AND -- compte en 0
               USER_ACCOUNT.WLT_STATUS_CODE IN ( 10, 20 ) -- PMV non bloqué
GROUP BY USER_ACCOUNT.USER_ACCOUNT_ID,
                      USER_ACCOUNT.LOGIN
HAVING SUM(toEuro2(NVL(PURCHASE.CAPTURE_CARD_AMOUNT,0) + NVL(PURCHASE.CAPTURE_OPERATION_AMOUNT,0) + NVL(PURCHASE.CAPTURE_COUPON_AMOUNT, 0), PURCHASE.CURRENCY_ID)) >= 50
;

Cordialement,
Agathe
Commentaire de Patrick Pereira [ 16/nov./06 18:26 ]
Je viens de lancer le script de retour arrière.
Commentaire de Patrick Pereira [ 16/nov./06 18:33 ]
Le retour arrière est terminé.
Je réassigne le JIRA à Edouard.
Commentaire de Antoine Koener [ 17/nov./06 09:59 ]

Je ne saisis pas comment la requète du départ qui visiblement était incorrecte à pu être validée...

Est-ce que cette nouvelle requète a été validée ?

Est-ce que la méthode de validation à changée ?

Ce sont peut être des points importants à eclaicir avant de repasser la requète non ?
Commentaire de Steven Harel [ 17/nov./06 10:08 ]
une grille de tests est en cours de préparation avec l'équipe des fraudes
les premiers tests n'étaient pas assez complets

on avait bien pris une partie des comptes à passer en 1 et on a vérifié qu'ils matchaient les critères, ça c'est ok

le souci est qu'on n'a pas pris de comptes en back office (qui ne matchaient pas au moins 1 critère), pour vérifier qu'ils ne se trouvaient pas dans la liste des comptes à passer en 1

nous allons vérifier rigoureusement le point 2 avec la prochaine grille de tests
Commentaire de Agathe Remy [ 17/nov./06 11:24 ]
Pour info, avec la correction sur la condition de date, nous obtenons 434 969 comptes à mettre à jour.

Cordialement,
Agathe
Commentaire de Edouard Laurent [ 20/nov./06 10:00 ]
Je pense qu'il manque la condition sur : USER_ACCOUNT.USR_COMPENSATION_RIGHT_CODE
Commentaire de Sébastien Mantanus [ 23/nov./06 09:56 ]
Voilà nous avons effectué tous les tests au niveau des fraudes, dans les deux sens, Agathe, peux-tu envoyer la requête à l'exploit pour qu'on puisse la faire passer au plus vite? car l'activité commence à être importante et on risque d'être vraiment débordés si ça ne passe pas vite...

Merci !
Commentaire de Agathe Remy [ 23/nov./06 12:41 ]
SELECT DISTINCT USER_ACCOUNT_ID
FROM
  USER_ACCOUNT,
   PURCHASE,
  (SELECT DISTINCT BUYER_ACCOUNT_ID, MIN(AUTHORIZATION_DATE) AS FIRST_PURCHASE_DATE
    FROM PURCHASE
    WHERE PCH_STATUS_CODE NOT IN (10,20)
    GROUP BY BUYER_ACCOUNT_ID
    HAVING MIN(AUTHORIZATION_DATE) < trunc(add_months(sysdate,-4))
   ) FIRST_PURCHASE
WHERE USER_ACCOUNT.USER_ACCOUNT_ID=PURCHASE.BUYER_ACCOUNT_ID AND
                PURCHASE.BUYER_ACCOUNT_ID=FIRST_PURCHASE.BUYER_ACCOUNT_ID AND
                USER_ACCOUNT.GRANT_EMAIL = 1 AND -- email OK
                USER_ACCOUNT.GRANT_LOGIN = 1 AND -- connexion OK
               USER_ACCOUNT.RELIABILITY = 0 AND -- compte en 0
               USER_ACCOUNT.WLT_STATUS_CODE IN ( 10, 20 ) -- PMV non bloqué
GROUP BY USER_ACCOUNT.USER_ACCOUNT_ID,
                      USER_ACCOUNT.LOGIN
HAVING SUM(toEuro2(NVL(PURCHASE.CAPTURE_CARD_AMOUNT,0) + NVL(PURCHASE.CAPTURE_OPERATION_AMOUNT,0) + NVL(PURCHASE.CAPTURE_COUPON_AMOUNT, 0), PURCHASE.CURRENCY_ID)) >= 50
;

Ce qui nous fait un total de 469 093 comptes à mettre à jour au 22/11/2006 minuit.
Commentaire de Sébastien Mantanus [ 23/nov./06 12:50 ]
Merci de faire passer impérativement le batch avant demain, pour des raisons de sécurité car on ne peut pas intervenir le W-E.

Merci!
Commentaire de Edouard Laurent [ 27/nov./06 15:22 ]
Voici le fichier des comptes, merci de le valider, ensuite je pourrais proceder à la mise a jour
Commentaire de Sébastien Mantanus [ 27/nov./06 17:02 ]
Les comptes de cette liste ont été testés, RAS, pour moi tout est OK, j'ai noté certains points de contrôles (nbr cptes en -1 et -2) pour comparer et re vérifier après.


Vous pouvez faire passer.

Merci
Commentaire de Edouard Laurent [ 27/nov./06 17:19 ]
Voila c'est fait
Commentaire de Agathe Remy [ 28/nov./06 09:52 ]
Bonjour Edouard,

Pourrais-tu mettre à jour la change_date des enregistrements modifiés afin que ceux-vi soient automatiquement mis à jour dans le Datawarehouse cette nuit, stp?

Merci:-)

Agathe
Commentaire de Steven Harel [ 28/nov./06 15:41 ]
peut-on automatiser cette tache ?

genre toutes les semaines, plutôt milieu de semaine
(nuit du mardi au mercredi)

ça nous permettra de faire des vérifs tous les mercredis matin

avec une seule variable pour les critères :
les paniers (+ de 50 euros) ont été passés avant j-4 mois
Commentaire de Edouard Laurent [ 28/nov./06 16:42 ]
Voila c'est fait pour la demande d'Agathe
Commentaire de Edouard Laurent [ 04/déc./06 15:27 ]
Patrice qu'est ce que tu penses de la demande de Steven ?
Commentaire de Patrice Boulanger [ 04/déc./06 15:37 ]
Je préférerai qu'on continue sur un mode manuel pendant quelques temps surtout si on modifie les critéres de la requête. On pourrait dire jusqu'à la fin de l'année. Ensuite, on automatise si aucun problème n'est détecté. Je pense qu'il s'agit là d'un sujet suffisamment sérieux pour qu'on ne se précipite pas.

Commentaire de Edouard Laurent [ 16/janv./07 10:22 ]
Pour info :

http://wikiexploit.lan:82/doku.php?id=edouard.laurent:projets:exploitation:passage_massif_des_compte_realibility_1
Commentaire de Edouard Laurent [ 16/janv./07 10:36 ]
Sebastien,

Cela fait : 32 775 comptes qui vont etre passer en 1, tu valides ?

Edouard
Commentaire de Sébastien Mantanus [ 16/janv./07 15:17 ]
Pour moi les résultats sont corrects.
Commentaire de Edouard Laurent [ 17/janv./07 15:20 ]
J'ai refait un comptage pour etre sur : 33 299 ajourd'hui

Est ce que tu peux refaire le comptage dans BO et me donner le chiffre que tu trouves ? merci

Edouard

Commentaire de Sébastien Mantanus [ 17/janv./07 16:24 ]
33 763 comptes pour moi...
Commentaire de Agathe Remy [ 17/janv./07 17:21 ]
Votre différence est due à la condition "premier panier vieux de plus de 4 mois ".
Dans le comptage d'ELA, on prend les comptes dont le premier panier est strictement inférieur à 4 mois.
Dans le rapport BI de SMO, on prend les comptes dont le premier panier est inférieur ou égal à 4 mois.

Agathe
Commentaire de Edouard Laurent [ 17/janv./07 18:23 ]
Ouf j'arrive enfin au meme comptage que toi, cependant il faut que l'on discute d'une condition encore, je reporte donc le passage des comptes a 1 a la semaine prochaine !

Commentaire de Edouard Laurent [ 22/janv./07 14:17 ]
voila le resultat de mon comptage : 36 585 , j'espere que l'on trouve la meme chose :~)
Commentaire de Sébastien Mantanus [ 22/janv./07 14:58 ]
ok c'est bon de mon côté, meme résultat
Commentaire de Edouard Laurent [ 22/janv./07 15:20 ]
C'est bon j'ai passé les compte a 1, est ce que c'est toujours OK pour toi ?
Commentaire de Sébastien Mantanus [ 22/janv./07 16:30 ]
c'est toujours ok pour moi
Commentaire de Edouard Laurent [ 05/févr./07 15:24 ]
Cela fait 8468 comptes, c'est bon pour toi ?
Commentaire de Sébastien Mantanus [ 05/févr./07 15:34 ]
c'est bon pour moi !

BI trouve 8491 ce qui est l'écart classique (comme vu la derniere fois)
Commentaire de Edouard Laurent [ 05/févr./07 15:42 ]
Voila c'est fait, tu peux faire la verification des comptes en -1 et -2

Edouard
Commentaire de Edouard Laurent [ 16/avr./07 17:17 ]
Voici la doc exploit qui permet de mettre a jour les comptes :

http://wikiexploit.lan:82/doku.php?id=edouard.laurent:projets:exploitation:passage_massif_des_compte_realibility_1

Cette demande est traitée
Commentaire de Cedric Favero [ 12/juin/07 17:55 ]
Il est toujours nécessaire d'effectuer cette tache regulièrement pour soulager le travail des fraudes.

Sebastien Mantanus étant parti , c'est moi qui vais gérer la validation des fichiers résultant de ces opérations.

Qui peut reprendre le process à l'exploitation dans l'attente d'une possibile automatisation du processus?
Commentaire de Justin Ziegler [ 08/août/07 16:51 ]
Steven, est ce que tu pourrais stp passer 5 minutes a documenter ce jira ?
Pourquoi fait on cela ? A quoi ca sert ?
Faut il changer l'appli pour éviter d'avoir à faire cela ?
Commentaire de Cedric Favero [ 29/août/07 17:55 ]
Je n'avais pas reçu le commentaire de justin et retombe donc dessus en venant voir ce qu'il en est.
Celà est tjrs d'actualité pour exclure des règles d'observation un grand nombre de comptes jugés fiables...

Steven,tu vois s'il faut qu'on en reparle... ?
Commentaire de Steven Harel [ 30/août/07 10:17 ]
pas vu le commentaire de justin
cédric s'occupe de suivre ce truc (doc, vérifs, ...) avec sebastien bruzzone son client
Commentaire de Justin Ziegler [ 03/sept./07 15:41 ]
cela nous éclarie pas franchement bcp comme doc :-)

on ferme le jira alors ?
Commentaire de Cedric Favero [ 03/sept./07 15:49 ]
Je peux prendre un moment pour vous expliquer le truc mais on est sous l'eau ces jours-ci...

Tu prefères l'avoir dans le JIRA on peut prendre 10min pour en discuter?
Commentaire de Justin Ziegler [ 03/sept./07 16:07 ]
si le jira doit rester ouvert, il vaut mieux mettre un peu d'explication dans le jira je pense. Comme cela tout ceux qui sont concerné en profiteront.
Commentaire de Cedric Favero [ 04/sept./07 14:56 ]
Alors, je détaille donc un peu la demande:

L'équipe des fraudes (Sebastien Bruzzone) valide chaque jour manuellement des centaines de paniers qui ont été placés en observation selon diverses règles gérées par des mots clés en code velocity,ceci afin de detecter en amont de possibles achats frauduleux et ainsi minimiser au maximum les risques d'opposition.

Ces reglès d'observation fonctionnent par palliers (montants) mais aussi par exclusion ( par exemple panier de plus de 200 euros sauf si pro , sauf si payé par porte-monnaie , etc...)

ex: d'un mot clé velocity placant un panier en observation pour un montant superieur à 200¿:
! $userConstants.RELIABILITY_HIGH.equals($buyer.reliability) && ! $buyer.isPro() && ! $purchase.isECarteBleue() && ! $purchase.useWallet() && ! $purchase.useCoupon() && ! $purchase.isNego() && $util.greaterThan($stats.Amount24H, 200) && $util.lessThan($stats.Amount24H, 301)

Une des variables très importante dans ce process est le $buyer.reliability puisqu'on exclue de nos premiers palliers de surveillance tous les comptes étant jugés "fiables" , c'est à dire étant en validation auto = 1 , selon les critères définis dans ce JIRA et le Wiki documenté par Edouard Laurent.

Le nombre de paniers placés en observation étant en permanence très important et en particulier les week-ends , il est crucial d'exclure de ces regles les paniers effectués par des comptes considérés comme fiables afin que :
-d'une part , ils soient validés automatiquement et non mis inutilement à l'état "réservé" pendant plusieurs jours
-d'autre part soit allégé le travail de validation manuelle des paniers par l'équipe des Fraudes , pouvant se concentrer sur des paniers mis en observation plus pertinemment.

En gros , ce process passe donc les comptes matchant les critères requis en validation auto 1 afin que leurs paniers ne tombent plus en observation inutilement.

J'espère avoir été assez clair et suis dispo pour toutes précisions.

Commentaire de Justin Ziegler [ 04/sept./07 17:13 ]
Merci pour ces explications tres claires.
Il manque juste un point concernant le process :
1/ vous demandez régulièrement à l'exploit de faire une manip prédéfinie par l'intermédiaire de ce jira ?
2/ vous laissez le jira pour qu'ils n'oublient pas de le faire, tout seul ?
3/ c'est exactement la meme manip a chaque fois ?
Commentaire de Steven Harel [ 04/sept./07 18:01 ]
la manip est toujours la même
il serai pas-mal de pouvoir l'automatiser
(genre routine de suppression de fiches à stock 0 avec émission d'un fichier, tests par cédric et validation)
Commentaire de Cedric Favero [ 04/sept./07 18:07 ]
Il était question de l'automatiser mais je pense que dans l'immédiat il est plus raisonnable de le faire ponctuellement par l'intermédiaire de ce JIRA , le temps de s'assurer que celà est bien rodé et que l'objectif visé est accompli sans erreurs.

Le dernier passage étant assez ancien , il doit y avoir un nombre importants de comptes concernés et une vérification attentive est donc nécessaire (on a une procédure de test pour çà , il faut que s'assurer que tout est toujours ok).

A priori la requete serait toujours la meme si les tests s'avèrent positifs , il faut juste garder un controle manuel à chaque fois (c'est moi qui m'en chargerais en l'occurence..).

L'idéal serait donc que je puisse avoir un fichier provenant de la requete documentée dans le Wiki afin que je puisse travailler dessus et vérifier qu'elle est correcte.

Merci.
Commentaire de Agathe Remy [ 04/sept./07 18:21 ]
Normalement, il existe un rapports BusinessObjects développé à l'époque pour Sébatien Montanus qui lui permettait d'extraire les informations nécessaires au contrôle sur la même cible que la requête de mise à jour de l'exploitation.

Pour une reprise en confiance, je pense qu'une vérification avec l'exploitation que c'est toujours le cas ne fera pas de mal.

Agathe
Commentaire de Cedric Favero [ 25/sept./07 15:11 ]
Agathe saurais tu me dire le rapport en question afin que je me penche un peu sur BusinessObjects par la meme occasion?
Une fois que je suis opérationnel de mon coté , on relance le process avec l'exploitation.
Merci.
Commentaire de Cedric Favero [ 10/oct./07 14:45 ]
C'est bon vu avec Agathe pour l'utilisation du rapport Business Objects.

151 377 comptes matchant les paramètres requis sont à traiter pour passer en validation auto 1 (reliability = 1)

Il me faut donc qqun à l'exploit pour lancer la requete et que l'on puisse comparer les résultats avant chaque passage du batch.

Bossant déjà avec Eric Vannier sur les problématiques de contrefaçon , je suggère de faire çà avec lui.

Patrice je te laisse assigner le JIRA à la personne la plus adaptée...
Commentaire de Cedric Favero [ 14/nov./07 09:42 ]
Ca fait plus d'un mois que j'attend un retour sur ce JIRA...
L'idée était de faire passer ce batch avant la période forte de Noel mais on est déjà en plein de temps...
Le nombre de paniers explose , il faut vraiment qu'on puisse soulager l'équipe des Fraudes pour qu'elle puisse travailler dans de bonnes conditions.

Qui plus est , la requete existant déjà, il s'agit simplement de comparer les résultats de la requete avec mon rapport Business Objects pour s'assurer que les chiffres correspondent .

Commentaire de Cedric Favero [ 14/nov./07 10:19 ]
j'ai 175 000 comptes en attente à ce jour , il y a vraiment urgence.
Commentaire de Patrick Pereira [ 14/nov./07 11:58 ]
J'ai lancé la requête de comptage. Je te tiens au courant.
Commentaire de Patrick Pereira [ 14/nov./07 14:29 ]
Tu peux trouver le fichier contenant les user_account_id à l'emplacement suivant :
W:\pereira\list_user_account_20071114.txt.gz

Il contient 177470 utilisateurs.
Dis-moi si c'est ok.
Commentaire de Cedric Favero [ 14/nov./07 14:54 ]
J'ai 175 007 comptes à ce jour dans mon rapport BI

Agathe,
Par rapport à ce que tu disais:

"Dans le comptage d'ELA, on prend les comptes dont le premier panier est strictement inférieur à 4 mois.
Dans le rapport BI de SMO, on prend les comptes dont le premier panier est inférieur ou égal à 4 mois. "

Celà te semble-il pouvoir expliquer l'écart de 2000 comptes?
Commentaire de Cedric Favero [ 14/nov./07 15:07 ]
En fait j'en ai 174205 si je fais wallet_status_code 10 ou 20 (non activé et activé)

Car j'avais pour ma part spécifié wallet_status_code different de 40 (bloqué)

En fait la requete pourrait dire USER_ACCOUNT.WLT_STATUS_CODE IN ( 10, 20,30 ) mais c'est un détail. (30 correspondant au statut "restreint")
Commentaire de Agathe Remy [ 14/nov./07 16:11 ]
Patrick,

Peux-tu voir avec Cédric pourquoi vous n'obtenez pas la même chose?
Je pense qu'il faut comparer la requête BI et celle que vous utilisez.
Je peux te montrer comment accéder à la requête BI?!

Merci:-)
Agathe
Commentaire de Cedric Favero [ 14/nov./07 17:17 ]
Bon ,vu avec Agathe , les deux requetes sont bonnes et correspondent.
La différence peut etre due à la date de premier panier dans BI mais rien de bloquant pour le passage du batch réellement urgent.

J'ai fait pour ma part des tests croisés: comptes en -1 , -2 , pmv bloqués..etc pour m'assurer qu'ils n'étaient pas repris par la requete et tout est ok.

Patrick , dis moi quand le batch peut passer , le plus tot étant le mieux , en evitant les fins de semaine evidemment...(semaine prochaine?)

Merci.
Commentaire de Patrick Pereira [ 15/nov./07 12:47 ]
Le traitement est passé.

Dites-moi si c'est ok.
Commentaire de Steven Harel [ 15/nov./07 13:07 ]
super, merci beaucoup
ça nous sauve,
cédric fait des vérifs pour voir si tout s'est bien passé

prochaine étape : l'automatisation du batch :)
Commentaire de Cedric Favero [ 15/nov./07 15:06 ]
Genial.
Merci d'avoir fait passer ce traitement en urgence.

J'ai repris mes comptes tests et les -2 , les -1 , les bloqués, etc.. sont bien restés à leur place.
Les comptes matchant les critères ont bien été passés en 1.
Une bonne chose de faite donc.


Concernant l'automatisation , je pense qu'il n'est pas nécessaire de le faire chaque semaine , un passage mensuel étant suffisant.
On pourrait par exemple programmer l'exécution tous les premiers mardi du mois...

Merci de m'indiquer en fonction des disponibilités de la base et autres considérations techniques à quelle date on pourrait le fixer afin que je synchronise l'éxecution de mon rapport Business Objects de mon coté.

Si je propose le mardi , c'est pour une logique comme suit:

-eviter le lundi
-reception des resultats de la requete par mail le mardi.
-vérification et tests de ma part pour confirmation
-passage du batch le jeudi

C'est une proposition,on en parle quand vous voulez pour les modalités.

Merci d'avance.






Commentaire de Patrick Pereira [ 20/nov./07 12:03 ]
Ca me va.
J'ai mis en place le traitement automatique qui s'exécute tous les premiers mardi de chaque mois et qui t'envoie par mail la liste de user_account_id à migrer.

Voyons le 4 décembre le résultat.
Commentaire de Cedric Favero [ 20/nov./07 12:07 ]
Ok super. Merci.
Commentaire de Cedric Favero [ 04/déc./07 11:38 ]
Vu avec Patrick , le process est en place, je ferme donc le JIRA.

Chaque premier mardi du mois , le resultats de la requete me sont envoyés.
Je lui donne mon retour par mail après vérifications et il me confirme le traitement des comptes.





[BIN-629] [Back Office] : ajouter le "droit de réponse vendeur" à l'univers item Création: 23/sept./09 17:03  Mise à jour: 16/mars/10 15:54  Résolue: 23/oct./09 10:12

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Steven Harel Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Extract des reponses vendeurs le 01 10 2009.xlsx    
Pays:
ALL - Tous

 Description   
nous allons avoir besoin de suivre la nouvelle fonctionnalité "droit de réponse".

on aimerait donc avoir, dans l'univers item, les commentaires des vendeurs aux notes des acheteurs.

 Commentaires   
Commentaire de Dalila Belkebir [ 23/sept./09 17:08 ]
Bonjour Steven,

Le projet de refonte Q/R est prévu pour novembre 2009.
A ce jour nous ne disposons pas des données Q/R dans le BI.

Nous comptons les intégrer au moment de la MEP en novembre.

Je te propose de revenir vers toi dès que les KPI du projet et son implémentation seront définis.

Cordialement,
Dalila.
Commentaire de Steven Harel [ 23/sept./09 17:34 ]
hi ! on ne parle pas de q/r mais du nouveau droit de réponse.

c'est quand un acheteur met 1/5 au vendeur en laissant "escroc" en commentaire de cette note. le vendeur peut "commenter" (ce n'est pas un message) la note de l'acheteur en disant "toi-même".

c'est visible sur la page des notes du vendeur dans sa boutique.

rien à voir avec le q/r si ?
Commentaire de Dalila Belkebir [ 23/sept./09 17:53 ]
Okayyyyyy

Effectivement rien à voir avec Q/R ... Désolée de ma première réponse trop spontanée et motivée :-)

Effectivement il y a bien un nouveau champ ds la base "SELLER_SCORE_FEEDBACK", nouveau champ que nous n'avons pas dans le BI.

=> Il nous faut donc récupérer la donnée dans l'alimentation avant de la mettre à dispo dans l'Univers. Donc un peu couteux pour nous.

Comment souhaites-tu la suivre ?
de manière assez régulière ou ponctuelle ? dans un rapport ou une extraction de données ?

Dalila.
Commentaire de Steven Harel [ 29/sept./09 11:39 ]
a priori de manière ponctuelle pour voir comment c'est utilisé. pas vraiment de rapport prévu par la suite
Commentaire de Dalila Belkebir [ 01/oct./09 17:41 ]
Steven,

Comme vu ensemble : d'abord un extract de données, ensuite on évalue le besoin.

Voici une répartition du nombre de réponses vendeur par note :
Nb d'item Nb de réponses vendeur Note du vendeur
14 161 / 524 / 0
253 027 / 906 / 1
210 635 / 702 / 2
572 530 1 / 274 / 3
2 253 462 / 1 750 / 4
16 869 084 / 3 317 / 5

Il y a en tout 7 800 réponses vendeurs max. D'où ma volonté d'attendre afin d'éventuellement remonter les infos ds le BI.
Tu trouveras également ci-jointe une extraction de données.

je te laisse regarder ces données. Si tu as besoin d'autre infos, n'hésites pas !

Cdlt,
dalila.
Commentaire de Dalila Belkebir [ 01/oct./09 17:42 ]
Pour un usage ultérieur, la requête d'extraction est dans T:\BI\01 - Demandes ponctuelles\03 - Back Office\Extract des réponses vendeurs.

Dalila.
Commentaire de Dalila Belkebir [ 23/oct./09 10:12 ]
Steven,

As-tu eu le temps de regarder l'extract ?


Cdlt,
Dalila.
Commentaire de Steven Harel [ 27/oct./09 16:36 ]
hello, merci pour ces infos.

j'ai 80 lignes en tout dans le doc. c'est le bon format mais pas assez d'infos pour pouvoir se faire une idée de l'utilisation.

est-ce qu'on peut programmer un nouvel extract de tous les commentaires vendeurs genre dans 10 jours. ça devrait nous permettre de voir comment c'est utilisé et modifier nos mots-clé en conséquence.

merci bcp
Commentaire de Dalila Belkebir [ 27/oct./09 18:34 ]
Hello Steven,

Je viens de refaire un extract ... je pense que tu vas avoir suffisamment d'infos à nalayser maintenant.

Le fichier est gros, il est dans le répertoire :
T:\BI\01 - Demandes ponctuelles\03 - Back Office\Extract des réponses vendeurs


Cdlt,
Dalila.
Commentaire de Steven Harel [ 05/nov./09 08:56 ]
merci ! je vais voir ça.




[APP-5203] Messagerie : problème boîte "back garantie auto" dans messagerie Création: 06/juil./05 18:06  Mise à jour: 25/juin/07 18:30  Résolue: 07/juil./05 15:28

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 8.0.2g
Version(s) corrigée(s): 8.0.3

Type: Bogue Priorité: Majeur
Rapporteur: Charlotte Fachan Attribution: Geneviève Beaujard
Résolution: Impossible à reproduire  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
dans la messagerie (pour ex boîte back question ach"), lorsqu'on veut transférer un message par le biais du lien "déplacer vers" ...."garantie auto", cela ne marche pas. Le mail reste dans la boîte initiale.

 Commentaires   
Commentaire de Geneviève Beaujard [ 07/juil./05 15:28 ]
jemina me dit que charlotte a du faire une erreur de manip




[EXP-2706] PB de mémoire Création: 25/sept./06 16:09  Mise à jour: 25/juin/07 18:59  Résolue: 10/oct./06 08:59

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Samir Beghdadi Attribution: ZZ_Arnaud Baali
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut Arnaud,

Il serait génial d'augmenter la RAM de mon pc qui n'arrive plus à suivre mais grave, depuis que j'utilise à la fois les deux applications du BI (BO et OWB) qui sont très gourmandes en mémoire.

Merci bcp





[DEC-576] rapport mev + SLTV Création: 02/avr./07 10:00  Mise à jour: 14/sept./07 15:31  Résolue: 10/avr./07 19:19

Etat: Fermé
Projet: Reporting
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Thomas Beylot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
hello

début de mois oblige, voilà le traditionnel jira pour demander les rapports de mise en vente et SLTV (pas besoin de générer les rapports de populations puisqu'un jira y référant explique que pour l'instant ils sont biaisés, en attendant réparation)


merci





[BIN-340] [Affiliation] : Optimisation du rapport Affiliation Achat Création: 05/juin/07 19:59  Mise à jour: 14/sept./07 18:04  Résolue: 01/août/07 17:30

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Ghislain Gridel Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Sur BI, le rapport Affiliation de validation des achats marche difficilement. Le temps de réponse est extrémement long.

est-il possible de trouver des pistes d'optimisation, svp ?

Merci.

Ghislain

 Commentaires   
Commentaire de Romain Czornomaz [ 13/juin/07 11:02 ]
Samir,

Afin d'améliorer la génération du rapport PriceMinister - Affiliation purchase checking, il faut optimiser la requete qui est effectué sur l'univers ITEM.

Pour cela, il faut créer une dénormialisation de purchase tracking dans la table ITEM.
voici les taches à effectuer:
- Modification de la table TF_ITEM pour ajouter les champs PCH_TRACKING_ID et PCH_TRACKING_DATE
- Modification des alimentations FULL / DAILY pour prendre en compte l'alimentation de ces champs
- Modification de l'univers ITEM pour ajouter la jointure de PCH_TRACKING_ID vers TRACKING -> TRACKING_GROUP
- Ajout dans l'univers ITEM de la classe PURCHASE TRACKING avec les objets suivants: objets de type dimension sur PCH TRACKING ID, PCH TRACKING NAME, PCH TRACKING GROUP ID, PCH TRACKING GROUP NAME, PCH TRACKING DATE et les filtres de type invites utilisateurs "Select purchase tracking group" et "Select purchase tracking"
- Modification du rapport pour ajouter l'invite utilisateur "Select purchase tracking group" dans la requete ITEM.

Romain





[BIN-384] rapport bilan coupon par mois Création: 18/oct./07 10:27  Mise à jour: 09/nov./07 17:51  Résolue: 29/oct./07 15:21

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Olivier Mathiot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
le rapport bilan coupon par mois plante tous les mois
et en plus il tourne pendant des heures
nous avons bcp de mal à suivre l'évolution de ce budget... qui repésente 90 000¿ par mois et qui a explosé de puis 2 mois
est il possible de l'optimiser ???

dasn le repértoire BI d'odile

 Commentaires   
Commentaire de Agathe Remy [ 29/oct./07 15:21 ]
Pour mémo technique :
Remplacement de l'index FK_PCH_COUPON sur la table TF_PURCHASE par un index bitmap.

Comme il y a beaucoup de valeurs nulles, l'optimisation obtenues est spéctaculaire:-)

Agathe




Installation du serveur de développement utilisant la dernière version de la stack Redhat/JBOSS (STUART) (INF-8)

[INF-10] Racking du serveur Création: 14/avr./08 10:33  Mise à jour: 14/avr./08 18:29  Résolue: 14/avr./08 18:29

Etat: Résolu
Projet: Infrastructure
Composants: Réseau
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Patrice Boulanger Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Le serveur sera l'un des serveurs 1950 qui n'est pas encore utilisé.

- Bi-proc/Dual core
- 16 Go de RAM mini
- 2x146Go en RAID 1

A racker dans la baie n° 7 (celle à fond à droite en entrant).

 Commentaires   
Commentaire de Stéphane Eccli [ 14/avr./08 18:29 ]
serveur racké




[EXP-4621] Installation de MS Project sur mon poste depuis le poste de Florian Création: 18/nov./08 18:44  Mise à jour: 19/nov./08 16:22  Résolue: 19/nov./08 16:22

Etat: Résolu
Projet: Exploitation
Composants: Installation
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Bloquant
Rapporteur: Dalila Belkebir Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
J'avais MS Project mon ancien poste occupé maintenant par Florian.
Peux-tu STP récupérer MSP du poste de Florian et l'installer sur mon poste ?

Sinon je ne peux pas mettre à jour le planning BI pour demain :-)

Merci.
Dalila.

 Commentaires   
Commentaire de Stéphane Eccli [ 19/nov./08 16:22 ]
ok




[BIN-598] [Sales] : Création des conditions prédéfinies "Last 7 user event days" et "Last user event month" Création: 23/juin/09 18:31  Mise à jour: 08/juil./09 19:17  Résolue: 08/juil./09 19:17

Etat: Fermé
Projet: Business Intelligence
Composants: Sales
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Dorian Porta Delsol Attribution: Geoffroy Vigneron
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello la BI team ,

Pourriez vous créer ces 2 nouveaux indicateurs :
"Last 7 user event days"
"Last user event month"

Dans FRANCE - USER EVENT en priorité. Puis ES et UK par la suite.

Merci :-)

 Commentaires   
Commentaire de Cyril Tanneau [ 06/juil./09 18:16 ]
Bonjour Dorian,

pour répondre à ta demande, nous avons créé les filtres:
- "Last 7 user event days" dans la classe User event creation date hierarchy de l'univers User event
- "Previous user event month" dans la classe User event creation date hierarchy du même univers.

Ces filtres sont disponibles pour les plateformes FR, ES et UK.

Peux-tu les valider?

Merci,

Cyril
Commentaire de Dorian Porta Delsol [ 07/juil./09 15:17 ]
C'est parfait ! Tout roule !

Merci




[EXP-5077] Identification des comptes professionnels avec FTP Création: 25/mars/10 10:24  Mise à jour: 25/mars/10 10:24

Etat: Ouvert
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Dorian Porta Delsol Attribution: Patrice Boulanger
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Est il possible de mettre un indice d'identification pour les professionnels disposant de compte FTP pour pouvoir les faire ressortir dans BI ?
L'idéal serait des marqueurs différents pour les flux de commandes et les flux d'import de stock.

Merci




Etude de mise en oeuvre d'une stratégie de sauvegarde des plateformes internes (EXP-753)

[EXP-754] Etat de l'existant en matière de données sur les plateformes internes Création: 03/janv./06 19:17  Mise à jour: 25/juin/07 18:55  Echéance: 12/janv./06 00:00  Résolue: 12/janv./06 11:54

Etat: Résolu
Projet: Exploitation
Composants: Etude
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Critique
Rapporteur: Alain Bonneaud Attribution: Pap Ndiaye
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 2 heures
Estimation originale: Non spécifié


 Description   
Etude des données présentes sur les plateformes internes et des volumétries correspondantes (plateforme système, serveurs utilitaires, serveurs BI, environnements de développement, d'intégration et de préproduction, ...) ainsi que des évolution envisagées pour l'année 2006

 Commentaires   
Commentaire de Pap Ndiaye [ 12/janv./06 11:31 ]
Je t'ai envoyé un mail récapitulatif des données sauvegardé actuellement et la capacité total de tous nos serveurs.




[EXP-753] Etude de mise en oeuvre d'une stratégie de sauvegarde des plateformes internes Création: 03/janv./06 19:14  Mise à jour: 25/juin/07 18:55  Résolue: 29/sept./06 13:56

Etat: Résolu
Projet: Exploitation
Composants: Etude
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Alain Bonneaud Attribution: Patrice Boulanger
Résolution: Corrigé  
Σ Estimation restante: 0 minutes Estimation restante: Non spécifié
Σ Temps consacré: 2 heures Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
EXP-754 Etat de l'existant en matière de donn... Sous-tâche Résolu Pap Ndiaye  
EXP-755 Elaboration d'une stratégie de sauveg... Sous-tâche Résolu Patrice Boulanger  
EXP-756 Evaluation d'une solution technique Sous-tâche Résolu Patrice Boulanger  

 Description   
Etude préalable à la mise en oeuvre d'une stratégie de sauvegarde sur les plateformes internes (plateformes systèmes, serveurs utilitaires, serveurs BI, serveurs de développement, environnements d'intégration, environnements de préproduction)

 Commentaires   
Commentaire de Patrice Boulanger [ 29/sept./06 13:56 ]
Nouveau JIRA: EXP-2751




[BIN-207] nb de paniers sur le mail PMV créditrés non activés Création: 26/oct./06 10:37  Mise à jour: 14/sept./07 17:30  Résolue: 30/oct./06 19:15

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut Mohamed,

je souhaiterais connaitre le nb de paniers générés par le tracking 1366040 chaque mois. Est-ce que je peux retrouver cette information à partir d'un des rapports existants sur BI?
Merci
Alexandra

 Commentaires   
Commentaire de Agathe Remy [ 30/oct./06 19:15 ]
Tu devrais trouver cette information dans le rapport Dossiers publics/Marketing/Purchase/Purchase by month.




[APP-16367] Articles n'apparaissant pas dans "recyclez vos achats" Création: 15/mai/07 12:29  Mise à jour: 06/juil./07 17:46  Résolue: 05/juin/07 14:44

Etat: Fermé
Projet: Application PriceMinister
Composants: Recyclage
Affecte la/les version(s): 14.0.1
Version(s) corrigée(s): 15.0.0

Type: Bogue Priorité: Majeur
Rapporteur: Cedric Favero Attribution: Geneviève Beaujard
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***
Classif1: MON COMPTE
Classif2: recyclage

 Description   
Pseudo: pgbg

Cette personne a déjà acheté 5 articles mais seuls 2 sont présents lorsqu'elle clique sur "recyclez vos achats"

Elle veut en particulier revendre l'article "Creative Zen Micro - Batterie" par ce biais mais l'article n'apparait pas (délai?)



 Commentaires   
Commentaire de Younès Charrière [ 15/mai/07 14:49 ]
Vu avec Renaud il y a plusieurs conditions à réunir pour pouvoir recycler ses achats :

private void prepareItemRecycleByBuyerSQL(Long lBuyerAccountId) {

setFrom("item, product");

addWhere("item.product_id = product.product_id");

addWhereConst("product.prd_status_code IN (?)", new Long[] {PrdStatusCode.VALIDATED_BO,PrdStatusCode.VALIDATED_SYS,PrdStatusCode.PURGED});

addWhere("item.buyer_account_id = ?", lBuyerAccountId);

addWhereConst("item.itm_status_code = ?", ItmStatusCode.CLOSED);

addWhereConst("item.seller_score >= ?", new Long(3)); // Note >= 3

addWhere("item.is_abandonned IS NULL"); // Article a été acheté

addWhere("NOT EXISTS (" + getProductSQL() + ")"); // Condition pour s'assurer que l'acheteur n'a pas déjà remis en vente l'article

}

Donc en résumé si je comprend bien il faut que l'article soit bien acheté, qu'il ait eu une note supérieure ou égale à 3 lors de l'achat, qu'il est en état CLOSED et que le produit auquel est rattaché l'annonce soit Validé par le BO ou bien par le système ou bien purgé, ... et d'autres obscures raisons :)

La personne décrite par Cédric a acheté 4 articles et non 5 (un a été refusé par le vendeur) et actuellement il peut recycler 3 de ses articles. Il y en a un par contre noté 3 qui rempli à priori les conditions ci-dessus mais qui n'est pas encore recyclable. J'aurais donc besoin d'un oeil éclairé sur la question :
http://bo.pm.lan/purchase_back?action=itemview&itemid=35867351&purchaseid=30985477

Merci.
Commentaire de Geneviève Beaujard [ 05/juin/07 14:42 ]
Petite precision:
addWhere("item.is_abandonned IS NULL"); il n'a pas eu de claim acceptée sur cet item.
Cedric et moi avons controlé les regles et nous sommes d'accord sur le resultat obtenu.

Commentaire de Younès Charrière [ 06/juil./07 17:46 ]
Ok alors je ferme le jira.




[APP-23066] Provenance : à mettre en place pour le UK Création: 13/nov./08 09:58  Mise à jour: 19/déc./08 17:59  Résolue: 25/nov./08 14:42

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 33.0.0 (CAT-E)
Version(s) corrigée(s): 37.0.0 (TX-D)

Type: Amélioration Priorité: Majeur
Rapporteur: Charles Decaux Attribution: Clement Balay
Résolution: Doublon  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Duplicate
doublon de APP-23119 [UK beta] Provenance UK Fermé
Pays:
GBR - Royaume Uni, FRA - France
Site: Prod
Projets PM archivés: UK - Plateforme BETA

 Description   
Afin de générer du trafic de la France vers le UK, je souhaite mettre en place une version de "provenance" qui permet à l'utilisateur anglais sur PM FR d'aller sur PM UK par le biais de l'affichage d'un layer

merci

 Commentaires   
Commentaire de Emeric Teil [ 25/nov./08 11:44 ]
Clément, il me semble qu'on peut fermer cette demande non ? (si c'est le cas, merci d'attacher le Jira traitant de cela).

Commentaire de Clement Balay [ 25/nov./08 14:42 ]
Oui, effectivement, on avait déjà traité la demande




[IMP-7709] SOLDES > POUR MISE A JOUR RAPIDE DES PRIX D'ORIGINE ET DE VENTE > Création format + profil > fashion > MILO-78 Création: 27/déc./10 10:51  Mise à jour: 29/déc./10 10:43  Résolue: 29/déc./10 10:43

Etat: Résolu
Projet: Paramétrage - Import
Composants: Demande commerciale
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Isabelle Weisbecker Attribution: Jérome Marianne
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: MILO-78
Modèle: fashion
Séparateur: Point-virgule (;)
Type de traitement:
Mise à jour/création annonces avec mise à jour/création produits (écrasement) , Mise à jour/création annonces avec mise à jour/création produits

 Description   
en préparation des Soldes, créer format et profil.
Je procéderai moi-même à l'extarction de l'inventaire sur BI et ferai le fichier d'import pour un taux d'import à 100% de réussite.

Créer 2 types de traitement : entrée et écrasement



 Commentaires   
Commentaire de Jérome Marianne [ 27/déc./10 17:19 ]
C'est le format type fashion qui doit être paramétré ou un format spécifique lié à l'extraction?
Commentaire de Isabelle Weisbecker [ 28/déc./10 10:40 ]
merci de crer le format "fashion"
Commentaire de Jérome Marianne [ 29/déc./10 10:43 ]
Les profils "Entrée/Sortie" et "Écrasement" ont été paramétrés avec le format de base "Fashion".





[APP-32515] Formulaires de contact pour vendeurs pros HS Création: 19/janv./11 18:15  Mise à jour: 20/janv./11 16:20  Résolue: 20/janv./11 15:35

Etat: Fermé
Projet: Application PriceMinister
Composants: Aide en ligne
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 84.0.1.2

Type: Bogue Priorité: Critique
Rapporteur: Habib-Sylvain Gourguet Attribution: Habib-Sylvain Gourguet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg     JPEG File screenshot-2.jpg    
Liens des demandes:
Duplicate
a pour doublon APP-32521 Dans la page Contact, la pop-up "Vous... Fermé
Pays:
ALL - Tous
Projets PM: *** A PLANIFIER ***

 Description   
Voir dans la FAQ.

Le noeud "Je suis un vendeur professionnel" s'ouvrait auparavant sur une quinzaine de formulaires de contact.

Ceux-ci sont aujourd'hui inaccessibles et il est devenu impossible de contacter l'équipe commerciale par ce biais.

 Commentaires   
Commentaire de Habib-Sylvain Gourguet [ 19/janv./11 18:23 ]
Vu avec Espérance (merci !). Il est envisageable de publier une v84.0.1.2 rapidement avant le début de l'integ de la v85.

Le bug vient du fait que l'équipe Edito SAV travaille actuellement à la mise en place d'une "FAQ pros" et à la réorganisation des infos dispos dans le noeud en question.

On souhaitait notamment supprimer la quinzaine de formulaires de contact pour n'en garder qu'un seul. Problème : la suppression d'une structure n'a pas besoin de respecter le process de publication habituel pour être effective (mea culpa).

@Gaël : on va profiter de l'occasion pour ne garder qu'un formulaire de contact à destination de l'équipe commerciale. On voit ça ensemble asap.
Commentaire de Gaël Seguillon [ 19/janv./11 18:33 ]
Merci Habib
@Esperance STP absolument cette semaine, les pros ne peuvent plus nous contacter, il faut vraiment pouvoir remettre le lien vers la boite de messagerie le plus vite possible
merci
Gaël
Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 11:08 ]
A publier sur REF et BRANCH pour FR (à traduire sur ES/UK) :

/online_help/Help Articles/Folder02 - FAQ/Contact/Folder06 - Je suis un vendeur professionnel/01 - Contact (équipe commerciale)
Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 11:29 ]
/online_help/Help Forms/Folder Vendeur PRO/Contact équipe commerciale (PROD ADMIN CO/Messagerie)
/ONLINE_HELP/CONTACT
/ONLINE_HELP/CONTACT/VOUS_ETES_UN_VENDEUR_PROFESSIONNEL
/ONLINE_HELP/CONTACT/VOUS_ETES_UN_VENDEUR_PROFESSIONNEL/CONTACT_EQUIPE_COMMERCIALE
Commentaire de Pablo Anton [ 20/janv./11 11:47 ]
Publié sur REF - ES

/online_help/Help Articles/Folder02 - FAQ/Contact/Folder06 - Je suis un vendeur professionnel/01 - Contact (équipe commerciale) - Spanish
Commentaire de Thomas Bentley [ 20/janv./11 11:50 ]
Egalement sur UK
Commentaire de Pablo Anton [ 20/janv./11 11:50 ]
Publié sur REF .- ES

/online_help/Help Forms/Folder Vendeur PRO/Contact équipe commerciale (PROD ADMIN CO/Messagerie) - Spanish
Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 11:53 ]
/online_help/Help Footers/(f) Contact (équipe commerciale)
Commentaire de Thomas Bentley [ 20/janv./11 11:57 ]
Suite message Pablo (11h50): egalement UK
Commentaire de Pablo Anton [ 20/janv./11 12:10 ]
Corrigé et publié sur REF - ES

/online_help/Help Articles/Folder02 - FAQ/Contact/Folder06 - Je suis un vendeur professionnel/01 - Contact (équipe commerciale) - Spanish
Commentaire de Pablo Anton [ 20/janv./11 12:18 ]
Publié sur REF - ES

/online_help/Help Footers/(f) Contact (équipe commerciale)
Commentaire de Thomas Bentley [ 20/janv./11 12:19 ]
Egalement sur UK
Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 12:26 ]
Contents et structures publiés sur REF et BRANCH pour FR/ES/UK.
Commentaire de Espérance Galouo-Lece [ 20/janv./11 14:50 ]
 - Trop de différence entre REF, BRANCH et INTEG (cf. screenshot-1)
 - Les dump pour l'INTEG sont directement pris de la BRANCH et non de REF.
Commentaire de Espérance Galouo-Lece [ 20/janv./11 14:52 ]
 - Et pas de formulaire en INTEG (cf. screenshot-2)
Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 15:27 ]
Pour les écarts entre REF, BRANCH et INTEG, rien d'anormal dans le sens où nous travaillions récemment sur la réorganisation de la FAQ pour la v85.

Pour le formulaire absent en INTEG, je suis en train de regarder. Tout est publié normalement sur CMS-BRANCH et CMS-REF, et a été testé avant publication sur FO-REF :

http://www.ref-fr.pm.dev/help/c_contact_pro/popup/true
Commentaire de Habib-Sylvain Gourguet [ 20/janv./11 15:35 ]
Publié sur BRANCH pour FR/ES/UK :

/ONLINE_HELP/CONTACT/VOUS_ETES_UN_VENDEUR_PROFESSIONNEL/CONTACT_EQUIPE_COMMERCIALE

Pointait sur un "OldContent" pour le formulaire. Sorry. :-(




[APP-32136] Historisation des FdP à l'autorisation Création: 06/déc./10 18:51  Mise à jour: 31/janv./11 16:10  Résolue: 24/janv./11 14:17

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 86.0.0 (TX-R)
Version(s) corrigée(s): 86.0.0 (TX-R)

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Arnaud Forgues Attribution: Yann Danot
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM: *** RESERVE ***

 Description   
Afin de permettre le rapprochement de VA à l'autorisation pour l'équipe BI, on souhaite stocker le montant des FdP à l'autorisation du panier.

Ces infos seront visible en BO sur la fiche article et autres (détails à venir)

 Commentaires   
Commentaire de Vincent Jouffe [ 31/janv./11 16:10 ]
ok




[IMP-6913] [UK] Extraction et paramétrage compte vendeur GamePimp Création: 03/sept./10 11:19  Mise à jour: 02/nov./10 14:01  Résolue: 02/nov./10 14:01

Etat: Résolu
Projet: Paramétrage - Import
Composants: Demande commerciale
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Jeremy Pallot Attribution: Jérome Marianne
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
GBR - Royaume Uni
Login: gamepimp
Séparateur: Point-virgule (;)
Type de traitement:
Mise à jour/création annonces (écrasement)

 Description   
Bonjour,

Pouvez-vous faire un extrait de stock (BI ou web service) et puis paramétrer le compte du vendeur Gamepimp. Pas de FTP, mise à jour via front office.

Pour mémoire c'est le compte avec 7000 annonces à valider.

Merci,

 Commentaires   
Commentaire de Jérome Marianne [ 09/sept./10 14:12 ]
Tests en cours pour tenter de valider par format import.
Commentaire de Jérome Marianne [ 13/sept./10 10:58 ]
Le fichier test n'a pas fonctionné.

Après avoir vu Patrick de l'équipe Exploitation il ne voit pas d'attribut qui pourrait agir sur le statut de la fiche produit.
Lui même de son coté ne peut le faire automatiquement car cela entraine des risques collatéraux sur la base.

J'ai envoyé un mail à Manuel Sadok pour voir s'ils connaitraient un autre moyen de valider les fiches automatiquement. J'attends sa réponse.
Commentaire de Jérome Marianne [ 14/sept./10 16:19 ]
Pour manuel il faut passer par l'import il ne voit pas de possibilité.

En attente d'infos de la part de Gael suite au mail de jerome Vivies.
Commentaire de Jérôme Viviès [ 14/sept./10 17:03 ]
Il y a eu des échanges par mail au sujet de cette demande - je recolle la conversation ici pour que tout le monde poursuive dans le JIRA :

De : Eric Vannier [mailto:eric.vannier@priceminister.com]
Envoyé : mardi 14 septembre 2010 11:47
À : Daniel Pintamalli
Cc : Gael Seguillon; Jeremy Pallot; JUSTIN ZIEGLER; exploitation; Christophe Garcia; Jerome Vivies; Manuel Sadok; Patrick Pereira; Sebastien Raguet; Pierre Bret
Objet : Re: [SUPERVISION] - Etat de sante de la plateforme 2010-09-14


Pour info, l'"out of memory" est du à un fichier plat issu des requêtes utilisateurs trop gros. Un jira va être crée pour limiter la taille de ce fichier pour éliminer ce risque de plantage.
Le 14 septembre 2010 11:41, Daniel Pintamalli <daniel.pintamalli@priceminister.com> a écrit :
Gaël, peux tu vérifier le PRO GamePIMP (UK)? On devrait lui assigner un format pour empêcher qu’il continue à remplir sa boutique par FO. Il en a déjà soumis 7000 et on se pose la question comment a-t-il fait pour en créer autant…
 
 
Daniel
 
De : Patrick Pereira [mailto:patrick.pereira@priceminister.com]
Envoyé : mardi 14 septembre 2010 11:33
À : Daniel Pintamalli; Eric Vannier; Sebastien Raguet; Pierre Bret

Cc : JUSTIN ZIEGLER; exploitation; Christophe Garcia; Jerome Vivies; Manuel Sadok
Objet : RE: [SUPERVISION] - Etat de sante de la plateforme 2010-09-14
 
Le traitement de cette nuit montre que le partenaire continue à insérer à la main (ou par script) des produits qui devront être valider ? Non ?
Ne faudrait-il pas le contacter pour qu’il arrête ?
 
 
De : Daniel Pintamalli [mailto:daniel.pintamalli@priceminister.com]
Envoyé : mardi 14 septembre 2010 11:28
À : Patrick Pereira; Eric Vannier; Sebastien Raguet; Pierre Bret
Cc : JUSTIN ZIEGLER; exploitation; Christophe Garcia; Jerome Vivies; Manuel Sadok
Objet : RE: [SUPERVISION] - Etat de sante de la plateforme 2010-09-14
 
Concernant GamePIMP :
 
Voir IMP-6913 : Passer les fiches produits en état "validé système"
 
L’équipe validation nous a demandé de valider en masse 7000 annonces soumis à la main pour un PRO anglais mais on s’est posé la question si ce n’est pas un script qui a fait cela car 7000 annonces à la main c’est impossible…
 
 
Daniel
 
 
De : Patrick Pereira [mailto:patrick.pereira@priceminister.com]
Envoyé : mardi 14 septembre 2010 10:57
À : Eric Vannier; Sebastien Raguet; Daniel Pintamalli; Pierre Bret
Cc : JUSTIN ZIEGLER; exploitation; Christophe Garcia
Objet : RE: [SUPERVISION] - Etat de sante de la plateforme 2010-09-14
 
Bonjour.
 
Affectation en rouge.
 
J’ajoute pour aujourd’hui Daniel pour la pb d’import sur GamePIMP.
J’ajoute Pierre Bret pour AdsBot Google.
 
Merci.
 
Patrick.
Commentaire de Jérôme Viviès [ 14/sept./10 17:17 ]
Salut,

Je résume pour faire un état des lieux :
- le partenaire a créé des milliers de produits via front office (!) - on se demande comment - et visiblement il continue...
- c'est un souci : les partenaires ne sont pas censés créer massivement des FP en FO avec des robots... Exploit' = pas glop !
- ces produits tombaient chez l'équipe Validation - qui a passé le partenaire en validation automatique
- pour les produits créés non validés, pas de possibilité pour la Validation de valider en masse (l'outil ne fonctionne pas)
- la demande de ce JIRA n'est pas valide : on ne peut pas extraire un stock et valider les produits par import

Solution proposée :
- contacter le partenaire, lui dire d'arrêter son mécanisme de soumission FO ;
- supprimer tous ses produits non validés ;
- lui demander un fichier d'import et faire un import standard.

Ok pour tout le monde ?

Merci de vos réponses rapides :)
Commentaire de Julien Buhagiar [ 16/sept./10 10:58 ]
J'ai appelé le pro (en vain).
Mail envoyé pour le prévenir que sa façon de lister les produits n'était pas la bonne.
Je lui communique le fichier d'import Jeux Vidéos (UK).
Si je n'ai pas de retour d'ici demain après-midi, je referai une tentative pour l'avoir au tél.

A dispo si besoin

Julien B.
Service Co.
Commentaire de Jérome Marianne [ 27/sept./10 18:24 ]
Des nouvelles de ce pro?
Commentaire de Gaël Seguillon [ 14/oct./10 13:13 ]
On laisse tomber on ferme le Jira
merci
Gaël
Commentaire de Aurélien Vergalli [ 14/oct./10 13:17 ]
Est-il possible de supprimer ses 4000 FP soumises qui nous "encombrent" dans le BO ?
Merci
Commentaire de Jérome Marianne [ 14/oct./10 15:51 ]
Il faut la validation de Gaël ou de Jérémy pour la suppression des 4000 fiches produits.




[BIN-124] étude sur les canaux d'acquisition des Op jeux concours Création: 03/août/06 10:39  Mise à jour: 14/sept./07 17:17  Résolue: 17/août/06 11:06

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Thomas Beylot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 1 jour
Temps consacré: Non spécifié
Estimation originale: 1 jour


 Description   
Hello,

suite à ma discussion avec Agathe (je ne comprends toujours pas à qui vont les jira en premier lieu même si je me doute que tu es en train de le lire, Agathe, alors je te parle sans te parler, bref) voilà ma toute dernière requête BO:

Contexte:

Lorsque nous montons des Op de jeux concours, nous recrutons un certains nombre de nouveaux prospects. Certains font une action sur le site directement après leur participation au jeu en provenant des points de redirects installés sur le jeu lui même, quand d'autres transforment à posteriori.

En cours d'OP, tous les prospects (exceptés ceux qui se dont inscrits dans la foulée du jeu, donc) sont intégrés à la base avec un first tracking défini au préalable. Ainsi, ces prospects rentrent dans le programme d'automatisation, mais aussi dans le programme de newsletters avec comme objectif de les faire acheter/vendre.

Au cours du temps, on remarque que ces prospects continuent de transformer et le taux de transfo sur cette base s'améliore donc.


Demande précise:

L'idée est donc de savoir par quel biais ces prospects transforment. Ainsi, j'aimerais croiser les first tracking du groupe jeu-concours (dans lequel on met toutes les OP, du jeu Tante Odette au jeu auto en passant par astérix) avec tous les last tracking pour savoir par quel moyen un prospect transforme. On pourra ainsi savoir si les messages qu'on lui envoie sont efficaces, ou si au final, on le "rachète" via un comparateur ou autre.

Petite précision, la première OP qui m'intéresse a commencé en octobre 2005, et donc la période s'étale jusqu'à aujourd'hui, et à fortiori ce rapport devrait me servir dans le temps (tous les mois, au même titre que purchase by month).


Je reste à votre dispo pour éclaircir ma demande au cas où.

merci !

 Commentaires   
Commentaire de Thomas Beylot [ 03/août/06 16:10 ]
bon alors en fait voilà ce qu'il me faut :

sur le tracking group jeux-concours
par tracking name

il me faudrait savoir par quel biais les comptes enregistrés avec le first tracking considéré ont acheté et/ou vendu sur le site (ex: newsletter, google, yahoo... etc.)

Ainsi, je pourrais savoir que sur tel tracking name, 60% des comptes enregistrés ont transformé via les mots clés, 10% via les news etc.
Je souhaiterais pouvoir faire cela sur chaque tracking name, mais aussi sur le tracking group en pondérant les différent résultats de chaque tracking name par le nombre de comptes de chacun.

Il me faudrait aussi à l'instant où le rapport est actualisé, le pourcentage des comptes du first tracking (sur le tracking name, et sur le tracking group) qui ont acheté, qui ont vendu, et qui ont acheté et vendu.


voilà, si ce n'est pas clair, tu sais où me trouver :)
Commentaire de Agathe Remy [ 03/août/06 17:29 ]
dimensions : purchase authorisation month, purchase tracking group name, purchase tracking name
indicateurs : New buyer count
conditions :
Authorized purchase
Select authorization month period
Select user first tracking
Commentaire de Samir Beghdadi [ 09/août/06 13:25 ]
Slt,
Le rapport sur de l'étude sur les canaux d'acquisition des Op jeux concours demandé par Thomas est enfin pret sous le nom
"Purchase/V1.1/Users by first tracking"
Commentaire de Agathe Remy [ 17/août/06 11:06 ]
Le rapport a été livré en Production sous :
Marketing/First tracking/User transformation by first tracking

Dis-nous ce que tu en penses?!

Merci:-)

Agathe




[APP-18282] [CBV]: Probleme de WAE_TYPE_CODE sur les évenements warranty Création: 18/oct./07 10:23  Mise à jour: 19/oct./07 15:00  Résolue: 18/oct./07 17:15

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 17.0.0
Version(s) corrigée(s): 17.1.0

Type: Bogue Priorité: Bloquant
Rapporteur: Romain Czornomaz Attribution: Renaud Dierickx
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Liens des demandes:
Similaire
similaire à APP-18276 CBV - bug sur le retour à la page con... Fermé
Pays:
FRA - France
Site: Prod
Projets PM archivés: Contrat "Bris et Vol" (Lot 2)

 Description   
Bonjour,

En vérifiant dans le BI les dénormalisations de la REFUND_DATE dans les Warranty nous avons découvert un bug concernant une garantie passé en état REFUNDED.
La garantie porte le numéro 2766.
En vérifiant les évéenements sur la garantie, l'évenement de REFUND (WAR_STATUS_CODE=50), on observe que le code de l'evenement (WAE_TYPE_CODE) est 110 (Misc) alors qu'il devrait etre 90.

Ce probleme est bloquant coté BI car cela nous empeche de créer correctement les dénormalisations de la date de remboursement sur les garanties.

Merci d'avance pour la correction,

Romain

 Commentaires   
Commentaire de Renaud Dierickx [ 18/oct./07 11:31 ]
Cette garantie est issus d'un bug (APP-18276) qui sera corrigé en V17.1.0.
Elle est associée à un article mais elle n'a jamais été payée...
Le BO l'a mise en REFUND car ils ne peuvent mettre un autre état.
Je vais donc corriger celle-ci via un script qui la mettre en DELETED (en mettant à jour la change_date).
Je mettrai un évènement de type 'Destruction' (WaeTypeCode = 30 : "Destruction de la garantie") et un description explicite (Change REFUND waranty status to DELETED to fix bug APP-18276 / APP-18282).

Ensuite, pour la modification d'état depuis le BO, je vais modifier la façon de faire :
- si passage à WarStatusCode.CONFIRMED -> WaeTypeCode.CONFIRMATION (70 : "Confirmation de la garantie")
- si passage à WarStatusCode.REFUNDED -> WaeTypeCode.ITEM_CLAIM (90 : "Annulation de la garantie par rétractation")
- si passage à WarStatusCode.RETRACTED -> WaeTypeCode.RETRACTATION (80 : "Annulation de la garantie par réclamation article")

Steven et Romain, vous êtes ok ?
Commentaire de Romain Czornomaz [ 18/oct./07 12:28 ]
Renaud,

Pour moi c'est ok.

Romain
Commentaire de Renaud Dierickx [ 18/oct./07 12:40 ]
J'ai écris le script et j'attends le retour de patrick pour le passer en production. (V:\Database\V17_1_0\dev\V17_1_0_APP-18276_FRA_correct_db_error_with_warranty.sql)

Pour voir ce que ça donne, voir screenshot (après passage du script en dev).
Commentaire de Renaud Dierickx [ 18/oct./07 17:15 ]
C'est bon, le script est passé !
Steven, merci d'alerter Claire que la garantie est passée en état "supprimée".
Commentaire de Sébastien Aubert [ 19/oct./07 14:48 ]
ok garantie supprimé en prod
Commentaire de Steven Harel [ 19/oct./07 15:00 ]
super, merci
la garantie a disparu des pages item et purchase
on a retenté la capture du panier




[APP-31524] Réclamation "en cours" mais transaction "rejetée" Création: 26/oct./10 18:28  Mise à jour: 17/janv./11 16:23

Etat: Ouvert
Projet: Application PriceMinister
Composants: Back-Office
Affecte la/les version(s): 79.0.3.2
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Habib-Sylvain Gourguet Attribution: Dispatcher (Pôle TX)
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** CHASSE ***

 Description   
Voir la fiche-article suivante :

http://bo.priceminister.com/purchase_back?action=itemview&itemid=143283322

Après vérification via rapport BI, une seule autre transaction était concernée, mais le bloc "claim" pouvait encore être modifié.

Ici, impossible, le bloc est figé.

Rien de bloquant, mais l'état de claim peut fausser quelques chiffres (rapports BI, Dashboard...).

 Commentaires   
Commentaire de Emeric Teil [ 17/déc./10 10:48 ]
Complément d'info par Laura :
"
En traitant les 7 jours, j’ai utilisé la macro « diff – pas de réponse – retour V part ».
 
Le reste ne sont que des mails envoyé manuellement :
- Mail blanc car c’est un pro, mais finalement vu avec Jeff pas de traitement pro vu le profil V.
- Suite au retour de l’Acheteur, une de nos nouvelles opératrices m’a transmis la transaction. Vu le montant j’ai voulu « forcer » le retour de l’article avant de rembourser, cf. les 2 mails du 22/10.
 
A noter que la transaction n’est plus retombée dans les 7 jours, suite à l’utilisation de la macro.
"




[META-TACHE] Modification des tracking sites-under + tracking e-mails questions (APP-26706)

[APP-26113] Tracking Question à un vendeur - t=40 Création: 29/juil./09 15:49  Mise à jour: 17/nov./09 15:44  Résolue: 01/sept./09 11:06

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 57.0.0 (CTN-N)
Version(s) corrigée(s): 57.0.0 (CTN-N)

Type: Sub-new feature Priorité: Majeur
Rapporteur: Ghislain Gridel Attribution: Dispatcher (Pôle CTN)
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Classif FONC: webanalytics
Projets PM archivés: Tracking affiliation

 Description   
Bonjour,

voilà le brief sur le tracking question.

1/ Contexte :
Aujourd'hui dans le pilotage des canaux marketing, nous distinguons le volume d'affaire généré par des trackings de celui généré sans tracking. Ainsi, l'ensemble tracking/No tracking = 100% du volume d'affaire PriceMinister.
Le volume d'affaire sans tracking correspond à du trafic spontané ou du référencement naturel.
Le volume d'affaire avec tracking inclue tous les canaux payants (acquisition), ainsi que la fidélisation (CRM et newsletters), les services (parrainage, widgets, souhaits, ami, question).
L'ensemble de ces trackings sont dédupliqués entre eux. Le dernier tracking avant l'authentification se voit attribuer le panier.

2/ Réflexion :
- Nous avons pris conscience que certains de ces canaux n'avaient pas de raison de rentrer dans ce système de tracking. ils prennent la place de canaux payants. C'est le cas du tracking « Question au vendeur » disposé sur tous les emails applicatifs signalant à l'acheteur que le vendeur a répondu à la question. Ce tracking vient s'imposer comme last tracking et le panier lui est attribué à la place d'un éventuel partenaire : « Kelkoo » ou « Google livres » par exemple. Le risque est de ne plus enchérir sur un mot clef réputé non rentable car la transformation n'est pas associée à ce mot clef. Dans les faits, ce mot clef peut être rentable mais le système actuel nous cache sa véritable rentabilité.

Voilà un exemple d'email :
------------------------------------
Bonjour guibrel,
 
fender13 a répondu au message que vous lui avez laissé à propos de l'article suivant :
 
Porte Bébé Dorsal
 
Pour consulter sa réponse, merci de cliquer sur le lien suivant :
 
http://www.priceminister.com/question?action=view&aid=225507967&t=40
 
Merci de votre confiance et à très bientôt sur PriceMinister.
 
http://www.priceminister.com
l'Achat-Vente Garanti
----------------------------------
- Nous nous apercevons en conséquence que sur les canaux que nous payons au CPC, nous ne retrouvons pas la rentabilité attendue malgré le bon travail effectué. Par exemple sur les liens sponsorisés, d'autres indicateurs nous démontrent que la stratégie est la bonne : Quality score élevé des campagnes, redirect précis sur les fiches produits et taux de clic élevé. Ce qui nous a amnée à entamer cette réflexion.
Le système de last tracking est-il défavorable à ces canaux car ils sont moins proche du last clic que d'autres ? mais pour autant restent des contributeurs importants à la transformation ? « Question au vendeur » doit-il continuer à usurper les paniers de nos partenaires ? est-ce juste ? Ne devrait-on pas mieux considérer ces canaux ?
- D'autres réflexions sont en cours sur l'intégration du CBV, et du revenus monétisation dans le calcul du résultat

3/ Problématique :
Toute modification du système implique une rupture avec l'historique et avec l'équilibre général des différents canaux. Nous devons donc être prudents.
Le tracking question représente environ 14% du volume d'affaire total du site. En enlevant le tracking question ces 14% vont se diffuser sur l'ensemble des autres canaux, de telle sorte que chaque canal devrait voir son volume d'affaire augmenter de 14% (toutes choses égales par ailleurs).

4/ Besoin :
Dans un premier temps, il faudrait pouvoir double tracker tous les emails applicatifs question au vendeur : le tracking comme aujourd'hui + le tracking xiti parallèle (appelé « autopromo »).
Nous pourrons ainsi voir si xiti donne des chiffres proches de BI.
Dans un deuxième temps, après analyse et après un « go » officiel, il faudra enlever le tracking t=40 définitivement.

Est-ce que cela est possible ? si oui quelles sont les différentes étapes techniques ?

A votre dispo pour toute question

Ghislain



 Commentaires   
Commentaire de Thomas Beylot [ 30/juil./09 09:23 ]
à noter dans ce brief qu'il faut souligner le fait que le tracking t=40 permet aujourd'hui de suivre sur l'activité quesitons:
- le VA et comm
- mais aussi un "taux de clic" (qui laisse présager du taux d'ouverture), vu que nous ne pouvons pas suivre celui ci directement.

> indicateurs qui nous ont permis récemment d'identifier un pb de délivrabilité des emails applicatifs !

il est donc primordial de retrouver ces indicateurs là sous quelque forme que ce soit (à priori techno tracking "autopromo") et de se rendre compte de l'écart entre ancienne strat et nouvelle strat.

A noter que ce faisant, nous perdons toute possibilité de faire de futures analyses BI sous le tracking questions.


thomas.
Commentaire de Charles Decaux [ 30/juil./09 11:21 ]
Une fois qu'on sera confiant sur la France, c'est-à-dire après le premier temps, il faudra mettre en oeuvre le deuxième temps sur ES et UK
Merci
Commentaire de Swan Desportes [ 30/juil./09 14:33 ]
Hello. Cette demande sera prise en compte dans le cadre du projet "plan de marquage" prévu pour la prochaine version.
Très concrètement, chaque mail ayant un code de tracking compris entre 10 et 50 se verra doté du système de tracking autopromo, en doublon du tracking classique.
Le système d'autopromos ne donne pas le taux d'ouverture. Nous le ferons avec le xtor qui propose un système pour suivre le taux d'ouverture.

A noter :
- sera fait pour tous les pays, tous les cobs
- absolument aucun impact sur le tracking PM actuel : pas d'activation du t=50, pas de risque de perte du t=40

Commentaire de Thomas Beylot [ 30/juil./09 14:58 ]
euh attention, car si sur le tracking 40 il y a consensus je ne crois pas que cela soit le cas sur les autres (parrainage, souhait etc)

en effet nous avons besoin d'analyses BI (first tracking notamment) sur ces sujets, et ça en le migrant dans autopromo nous ne l'aurions plus. J'en ai déjà fait part à Odile qui était ok.


thomas
Commentaire de Fabrice Feugas [ 27/oct./09 19:14 ]
Corrigé avec le projet "tracking affiliation" --> Il n'y aura plus de t=40 dans les e-mails questions




[EXP-931] Normaliser la documentation des serveurs. Le faire obligatoirement aprés une installation de serveur. Création: 18/janv./06 16:39  Mise à jour: 25/juin/07 18:55  Résolue: 30/janv./06 11:54

Etat: Fermé
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Jérémie Bennejean Attribution: Sébastien Tournay
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Ex pour Jacquard :

¿ Configuration matérielle
Marque: DELL
Modele: Poweredge 2850
Processeur: Intel Bi Xeon 3 Ghz
8 Go de DDR2
6 disques durs 146 Go scsi
Garantie bronze 3ans j+1
1 carte raid bi-canal PERC 4e/Di (Intégré)
2 cartes raid bi-canal PERC 4/DC
2 baies powervault 220s 14 disques durs scsi 146 Go en RAID 10

Service TAG de JACQUARD 2SZVT1J
Service TAG de la baie 1 BNFYT1J
Service TAG de la baie 21 CNFYT1J

Notre numéro client DELL : FR2325228
Numéro de téléphone du support : 0825 387 270
Garantie bronze valable jusqu'en : septembre 2008

DELL OPEN MANAGE --> https://jacquard:1311/servlet/OMSAStart?mode=omsa


 Commentaires   
Commentaire de Sébastien Tournay [ 30/janv./06 11:54 ]
Je ferme cette demande. Il faut suivre cette documentation dans le WIKI en fonction de chaque nouveau serveur. La demande de documentation sera formulée dans la tache JIRA correspondant à l'installation du serveur




[BIN-315] [Jeu Super Vendeur ES] : Extract membres Espagne Création: 05/avr./07 12:00  Mise à jour: 14/sept./07 18:03  Echéance: 11/avr./07 00:00  Résolue: 11/avr./07 18:22

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Nydia Yallico Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne

 Description   
Bonjour,

nous lançons le jeu super vendeur en Espagne le 17 avril 2007, aussi nous avons besoin d'un extract des membres du site Espagne sur le ciblage suivant :

- abonnés à au moins une news y compris offres partenaires

L'idéal serait d'avoir un rapport sous BI pour pouvoir exploiter ces données.

date limite de livraison le mercredi 11 avril

Merci,

Nydia et Charles

 Commentaires   
Commentaire de Agathe Remy [ 05/avr./07 18:29 ]
Nydia et Charles,

Pouvez-vous me dire quels sont les informations qui vous sont nécessaires :
email
pseudo
???

Merci:-)
Commentaire de Agathe Remy [ 10/avr./07 19:16 ]
Nydia,

J'ai créé un rapport "Optin emails listing" dans le répertoire Spain/Games dans BusinessObjects.

Dis-moi s'il te convient?!

Et n'hésite pas si tu as des questions...

Agathe
Commentaire de Nydia Yallico [ 11/avr./07 18:20 ]
Merci Agathe,

le rapport me convient tout à fait !

Nydia
Commentaire de Agathe Remy [ 11/avr./07 18:22 ]
Je clôture donc ce JIRA:-)

Agathe




[BIN-297] Revenus par catégorie par mois : données incohérentes Création: 27/févr./07 19:40  Mise à jour: 14/sept./07 18:02  Résolue: 01/mars/07 20:05

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Charles Decaux Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Data bizarres CA.xls    
Pays:
FRA - France

 Description   
Dans le rapport Mes Dossiers --> Favoris --> Charles --> CA par catégorie

Les données de décembre 2006 sont très inférieures à celles de janvier 2007 ce qui me semble étonnant.
En pièce jointe les données que j'ai obtenues sous BI

Est-ce qu'on explique une telle différence ?

Merci de ton retour

Charles




[BIN-320] [Cobranding/Vehicle] : Evolution des rapports de cobranding Auto suite à la mise en place de la nouvelle offre Création: 07/mars/07 17:35  Mise à jour: 02/janv./08 11:20  Résolue: 02/janv./08 11:20

Etat: Fermé
Projet: Business Intelligence
Composants: Partners
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Ghislain Gridel Attribution: Romain Czornomaz
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Agathe,

Les rapports (rappots de l'Intranet) des co-brandings auto sont cassés depuis le 1er mars. En effet il n'y a plus de paiement donc les dépôts d'annonces ne sont plus comptabilisés.

Cela est très problématique.

Comment faire ? Peut-on faire un rapport BI ?

La deadline est le 31 mars pour trouver une solution.

Merci de ton retour.

Ghislain

 Commentaires   
Commentaire de Ghislain Gridel [ 12/mars/07 10:51 ]
Agathe,

as-tu pu mettre cette demande sur ton planning ?

Je suis incapable de donner des chiffres à mes partners... malheureusement.

Merci de me tenir au courant.

Ghislain
Commentaire de Agathe Remy [ 12/mars/07 12:35 ]
Nous en raparlerons demain à la réunion Post Mortem "Nouvelle offre auto"...

Agathe
Commentaire de Agathe Remy [ 13/avr./07 16:48 ]
Romain,

Peux-tu faire valider les spécifications des rapports?

Merci:-)

Agathe
Commentaire de Ghislain Gridel [ 26/avr./07 12:27 ]
Agathe,

il s'agit de créer un nouveau rapport listant les nouveaux membres qui font un premier dépôt d'annonce auto.

Pour redoute, libé et Midi Libre.

Ce rapport est à adresser à Thomas Merlin.

Ghislain
Commentaire de Ghislain Gridel [ 26/avr./07 12:29 ]
IL faudra aussi l'nvoyer au partenaire.

Merci.

Ghislain
Commentaire de Romain Czornomaz [ 14/juin/07 11:56 ]
Ghislain,

Je bloque la demande en attendant que les decisions statégiques soient prises.

Bonne journée,

Romain
Commentaire de Agathe Remy [ 02/janv./08 11:20 ]
La demande a été annulée.

Agathe




Installation serveur outils de développement (PERRIER) (INF-7)

[INF-13] Racking du serveur Création: 14/avr./08 10:54  Mise à jour: 14/avr./08 18:28  Résolue: 14/avr./08 18:28

Etat: Résolu
Projet: Infrastructure
Composants: Réseau
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Patrice Boulanger Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Le serveur sera à prendre dans le stock des 1950 non utilisés.

Configuration:

- 1950, bi-proc/dual core
- 8 Go de RAM
- 2x146Go
- carte FC (attention compatibilité PCI-X / PCIe)

Ce serveur doit être raccordé au SAN CX3-20.

A racker dans la biae dév (n°7)

 Commentaires   
Commentaire de Stéphane Eccli [ 14/avr./08 18:28 ]
ok serveurs rackés




[INF-40] Temps réseau ou accés ruinart lent Création: 25/avr./08 16:46  Mise à jour: 15/juil./08 14:06  Résolue: 15/juil./08 14:06

Etat: Résolu
Projet: Infrastructure
Composants: Réseau
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Nicolas Chauveau Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
L'équipe dev qui se trouve dans le couloir entre QDC et le BI a des pb de lenteur :
- Accès aux répertoires 'group'
- CVS
- wiki
- Jira
- eclipse (qui accède à Ruinart pour CVs et à U: pour les fichiers sources distants)

hypothèses :
- Ruinart très lent
- Pb réseau

?

Pour plus d'info voir : Manuel Sadok , Edouard Gomez-Vaëz




 Commentaires   
Commentaire de Stéphane Eccli [ 15/juil./08 14:06 ]
allegement en cours




[BIN-485] [Media] : Nombre de nouveaux vendeurs "vidéo" Création: 11/sept./08 12:39  Mise à jour: 10/juin/09 19:56

Etat: Ouvert
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Cosmétique
Rapporteur: Thomas Beylot Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello

je souhaiterais pouvoir avoir sous BI un rapport présentant le nb de vendeurs par mois ayant fait leur première vidéo.
je ne me rends pas compte de la difficulté mais comme ça j'ai l'impression qu'il s'agit d'un rapport simple non ? si oui je peux peut être assister à sa création ?

merci beaucoup

 Commentaires   
Commentaire de Agathe Remy [ 15/oct./08 17:02 ]
Bonjour Thomas,

Après étude, pour te fournir ce nouvel indicateur (nb de vendeurs ayant déposés leur 1ère vidéo), il nous faut créer une dénormalisation (date de 1er dépôt d'une vidéo) dans le Datawarehouse et donc faire évoluer l'alimentation.
Ceci est donc plus coûteux que de simplement créer un indicateur dans l'univers.
Cette information est-elle donc réellement nécessaire pour justifier ce coût (et si oui pourquoi) ?

Merci.
Agathe
Commentaire de Thomas Beylot [ 21/nov./08 09:03 ]
Hello

désolé j'ai mis du temps à répondre.

pour donc apporter une réponse concrète ben je te dirais que oui c'est important. Et pour le justifier, ben je sais pas trop quoi te dire mis à part que ce serait comme de ne pas regarder le nb de nouveaux acheteurs ou vendeurs par mois...
tu en veux plus ?


thomas
Commentaire de Agathe Remy [ 21/nov./08 14:11 ]
Aide-toi et le ciel t'aidera...
Ce que je te demande, c'est une justification business concrète, du type : "cela me permettra d'évaluer, de prioriser ou de suivre telle ou telle action prévue à telle date dont l'apport en VA ou CA estimé est de tel montant"

Agathe
Commentaire de Thomas Beylot [ 21/nov./08 14:54 ]
ok alors
"ça me permettra de suivre toutes les actions qu'on pourrait mettre en place pour recruter de nouveaux vendeurs vidéo et donc d'améliorer la communication à faire si les chiffres constatés ne sont pas bons"

et

"ça me permettrait de mieux diagnostiquer une éventuelle chute des dépôt d'annonces vidéo, en sachant par exemple si c'est à cause d'un manque d'adhésion au service (joue sur fid) ou d'un manque de visibilité (joue sur recrutement de nouveaux vendeurs vidéo)"

par exemple

merci




[BIN-472] [Marketing] : Evolution du rapport "1000Mercis - Buyer value" Création: 05/août/08 10:34  Mise à jour: 04/sept./08 17:41  Résolue: 07/août/08 09:50

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Thomas Beylot Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello

il faudrait faire évoluer la requête de ce rapport car nous avons depuis sa création mis en place de nouveaux groupes de tracking. Or je ne peux modifier la requête depuis mon compte sous BI.

Il faudrait que les champs PL-Mode et PL-culturelle soient compris dans le filtre de référence.


merci

thomas

 Commentaires   
Commentaire de Agathe Remy [ 05/août/08 11:54 ]
Le rapport est dans le répertoire Dossiers publics/Subscription

Agathe
Commentaire de Cyril Tanneau [ 07/août/08 09:50 ]
C'est bon, j'ai ajouté les deux invites demandées dans la requête, tu pourras les sélectionner pour les prochains rapports.

Peux-tu valider et clôturer le Jira?

Merci,

Cyril
Commentaire de Agathe Remy [ 04/sept./08 14:49 ]
Bonjour Thomas,

Peux-tu valider ce JIRA afin que nous puissions le clôturer?

Merci.

Agathe
Commentaire de Thomas Beylot [ 04/sept./08 17:39 ]
super merci Cyril.

thomas




[INF-513] boite générale google mail pour le back office Création: 10/août/10 12:23  Mise à jour: 13/août/10 14:16  Résolue: 13/août/10 14:16

Etat: Résolu
Projet: Infrastructure
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Steven Harel Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
nous avons de tâches qui doivent être gérées par toute l'équipe
ces tâches impliquent l'envoi de rapports/fichiers/fax du BI, de partenaires ou de membres

on ne peut pas utiliser les alias réservés à des groupes restreints

il nous faut donc une boite google mail générale pour le back office
qui recevra tous ces docs et les triera par objet

merci

 Commentaires   
Commentaire de Steven Harel [ 12/août/10 11:49 ]
nom de la boite :

service.clients@priceminister.com

merci
Commentaire de Stéphane Eccli [ 13/août/10 14:16 ]
done




[EXP-662] Création d'un enregistrement LATONE pour notre DNS interne Création: 22/déc./05 10:56  Mise à jour: 25/juin/07 18:55  Echéance: 22/déc./05 00:00  Résolue: 22/déc./05 15:25

Etat: Résolu
Projet: Exploitation
Composants: Evolution
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Sébastien Tournay Attribution: Pap Ndiaye
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 20 minutes
Estimation originale: 20 minutes


 Description   
Il faudrait créer dans notre dns interne un enregistrement pour latone.jm.lan (alias latone). Adresse IP à venir. Il s'agit de la bdd BI de PROD à laquelle nous allons accéder via l'ARKOON pour administrer différentes instances Oracles.

http://latone:5500/em/ DW
http://latone:5501/em/ OWREP
http://latone:5502/em/ BOREP


 Commentaires   
Commentaire de Sébastien Tournay [ 22/déc./05 13:10 ]
l'@IP est 10.150.28.88 sur le réseau privé de PROD




[BIN-115] ajout de messages automatiques dans les bilans Vendeurs Création: 06/juil./06 12:02  Mise à jour: 14/sept./07 17:04  Résolue: 10/juil./06 14:11

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Elodie Pasquale Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures


 Description   
Bonjour,

2 nouveaux messages automatiques partent depuis juin 06 et sont à ajouter dans les bilans Vendeurs sous BI.
Il s'agit de :

M22-1ereMiseEnVente-j24h
code tracking : 1396045

M22bis-1ereMiseEnVente-j30
code tracking : 1402140

Merci

Elodie
elodie.pasquale@priceminister.com
Tel : +33 (0)1 42 78 87 15

 Commentaires   
Commentaire de Samir Beghdadi [ 10/juil./06 14:11 ]
Slt,
Je te confirme l'ajout des deux messages dans les bilans Vendeurs.
A toi de tester!!!!!

Merci.
 





[BIN-685] [So Colissimo] Ajouter deux variables dans l'univers USER ACCOUNT pour édition d'un rapport Création: 05/août/10 15:41  Mise à jour: 15/oct./10 10:03  Résolue: 31/août/10 18:45

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Thomas Landru Attribution: Fabrice Lima-Lopes
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Dans le cadre du projet So Colissimo on souhaiterait éditer un rapport BI au sujet des vendeurs transfrontaliers ayant chochés so colissimo et chronopost dans leurs préférences vendeurs.

Pour cela il faudrait intégrer dans BO les variables suivantes :

- user_account.supports_shipping_colissimo
- user_account.seller_country_id

Merci d'avance !

 Commentaires   
Commentaire de Habib-Sylvain Gourguet [ 06/août/10 16:39 ]
Et "puisqu'on est dessus" (dixit Agathe :-)...

Merci d'ajouter une dimension "operation creation month" dans le dossier "User wallet operation" de l'univers USER ACCOUNT.

Il n'existe pour le moment qu'une dimension "operation creation date".
Commentaire de Fabrice Lima-Lopes [ 31/août/10 18:45 ]
Bonjour,

Les nouvelles dimensions ont été ajoutées dans l'univers USER ACCOUNT.


Classe Seller:
--------------
-Seller allows SoColissimo shipment? (uniquement pour la France) : Indique si le vendeur a accepté le mode d'expédition "SoColissimo".
-Seller country Id : Identifiant du pays d'expédition de vendeur.
-Seller country name : Nom du pays d'expédition de vendeur.
-SoColissimo seller (uniquement pour la France) (Filtre) : Filtre les vendeurs ayant accepté le mode d'expédition "SoColissimo".
 

Classe User wallet operation :
-----------------------------
-Operation creation month : Mois de création de l'opération.


Peux tu valider la nouvelle fonctionnalité stp?

Merci.
Commentaire de Agathe Remy [ 13/sept./10 10:04 ]
Bonjour Habib,

Stp, peux-tu valider la demande afin que nous puissions la fermer?

Merci,
Agathe
Commentaire de Agathe Remy [ 14/oct./10 15:40 ]
Bonjour Habib,

Stp, peux-tu valider la demande afin que nous puissions la fermer?

Merci,
Agathe
Commentaire de Habib-Sylvain Gourguet [ 15/oct./10 09:32 ]
Testé, c'est parfait.

Merci !




[BIN-671] [BackOffice] : Créer un dossier BO Working GENERAL dans Dossiers Publics Création: 04/mai/10 16:55  Mise à jour: 08/nov./10 11:52  Résolue: 06/mai/10 15:36

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Pierre Smith Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word Réorganisation des dossiers et accès à Business Objects pour le Back Office.docx    
Pays:
ALL - Tous

 Description   
- Créer un fichier BO Working dans Dossiers Publics qui absorbe les actuels France / Spain / UK
- Donner le plein accès à modification au login ur_backoffice
- Permettre la consultation des dossiers par le login uv_backoffice

Descriptif du rendu final disponible dans V:\Paramétrage\BI "Réorganisation des dossiers et accès à Business Objects pour le Back Office.docx"

 Commentaires   
Commentaire de Pierre Smith [ 05/mai/10 11:36 ]
Pour précision, on souhaiterait renommer le fichier à la place de "BO Working"

On voudrait avoir "Requêtes Back-Office"

Est-ce faisable ? Merci
Commentaire de Habib-Sylvain Gourguet [ 05/mai/10 11:39 ]
Le fichier cité par Pierre en PJ.
Commentaire de Agathe Remy [ 05/mai/10 13:04 ]
Bonjour,

Comme les dossiers sont classés par ordre alphabétique, nommer ce nouveau dossier "Requêtes Back-Office" le placerait entre "France" et "Spain".
Que pensez-vous de proposer un autre nom ?

Agathe
Commentaire de Agathe Remy [ 05/mai/10 13:07 ]
Si vous voulez qu'il soit placé tout en bas, nous pouvons le nommer "ZZ - Requêtes BackOffice".
Qu'en pensez-vous?

Agathe
Commentaire de Habib-Sylvain Gourguet [ 05/mai/10 13:40 ]
Ok pour moi.
Commentaire de Pierre Smith [ 05/mai/10 13:52 ]
Ne peut-on pas plutôt l'appeler Back-Office Requêtes pour qu'il passe en premier ?
Commentaire de Agathe Remy [ 05/mai/10 14:21 ]
Ok pour "BackOffice Requêtes" (BusinessObjects n'aime pas trop les "-" dans les noms de dossier...)
Commentaire de Agathe Remy [ 06/mai/10 15:36 ]
Bonjour,

Le dossier "BackOffice Requêtes" a été créé et livré en Production.
Vous avez le droit de faire ce que voulez dedans avec l'utilisateur "ur backoffice" : créer des nouveaux dossiers et rapports, les supprimer, les planifier, etc...
L'utilisateur "uv backoffice" a accès en rafraîchissement et planification à tous les documents que vous créerez dans ce dossier, mais sans droit de modification ou suppression.

Je vous laisse donc migrer les rapports de BO Working dans la nouvelle arborescence que vous voulez mettre en place.

Lorsque vous aurez terminé, je vous prie de me le signaler afin que je supprime les anciens répertoires Bo Working.

Bien sûr, nous restons à votre dispo si vous avez des questions.
Agathe
Commentaire de Agathe Remy [ 13/sept./10 10:10 ]
Bonjour Habib,

Stp, peux-tu valider la demande afin que nous fermions le JIRA?

Merci,
Agathe




[BIN-590] [Marketing] : Rapport de suivi du taux d'annulation par type de produit Création: 09/juin/09 09:21  Mise à jour: 18/nov./10 18:07

Etat: Ouvert
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Thomas Beylot Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Comme vu ensemble en point bi mensuel, je créé donc le jira pour trace de la demande. Très rapidement il s'agit de mettre sur pied un rapport nous permettant de suivre le taux d'annulation des vendeurs particuliers et ce par catégorie de produit.

Brief à venir dès lors que nous saurons quand la demande sera planifiée ?

thomas.




[APP-20582] migration templates de mail d'un groupe à l'autre Création: 20/mai/08 17:44  Mise à jour: 28/mai/08 10:09  Résolue: 26/mai/08 14:22

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 22.1.0

Type: Tâche Priorité: Mineur
Rapporteur: Steven Harel Attribution: Renaud Dierickx
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel migration vers comptabilité - fraudes.xls     Microsoft Excel templated pmv.xls     Microsoft Excel templateid pmv.xls    
Pays:
FRA - France
Projets PM archivés: Maintenance TX-A

 Description   
on aimerait migrer certains templates de mails appartenant à plusieurs groupes de mails vers un nouveau groupe de mails

en pièce jointe le fichier excel avec le titre de chaque mail, son templateid, son groupid de départ et son groupid d'arrivée.

il serait pas-mal de pouvoir garder les mêmes templateid histoire de ne pas fausser les rapports du bi

 Commentaires   
Commentaire de Renaud Dierickx [ 26/mai/08 13:56 ]
Y -a-t-il quelque chose de similaire à faire en Espagne ?
Commentaire de Steven Harel [ 26/mai/08 14:29 ]
yes, mais c'est un autre fichier puisque les templateid sont différents pour les mêmes messages

rocio, peux-tu créer un nouveau groupe et faire un fichier comme le mien pour l'espagne ?

merci
Commentaire de Rocio Perez-Garcia [ 27/mai/08 09:27 ]
Fichier avec templateid ESP
Commentaire de Steven Harel [ 27/mai/08 09:35 ]
rocio,
dans ton fichier tu mets un groupid d'arrivée alors qu'il n'est pas créé en prod (?)
il faut d'abord créer le groupe, le positionner dans les messages type (en prod) et indiquer ensuite dans ton fchier quel est son id.
renaud ne va pas pouvoir migrer des messages vers un groupe qui n'existe pas.
Commentaire de Rocio Perez-Garcia [ 27/mai/08 10:00 ]
Ah ok, je n'avais pas tout compris. C'est fait.
Commentaire de Rocio Perez-Garcia [ 27/mai/08 10:01 ]
Merci de prendre en compte pour ESP seulement le fichier templateid




[IMP-3222] transfert de stock de thierrytame vers plaisirdelir Création: 05/févr./09 10:38  Mise à jour: 30/oct./09 15:43  Résolue: 10/févr./09 14:27

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Jany Marimoutou Attribution: Fotigui Tangara
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File 20090209_stock_thierrytame.csv     Text File thierrytame_stock.txt    
Pays:
FRA - France
Login: thierrytame vers plaisirdelir
Séparateur: N/A
Type de traitement:
N/A

 Description   
message reçu :

j'ai actuellement une boutique : thierrytame (part) et nous avons ouvert avec le statut pro la boutique : plaisirdelir
nous souhaiterions faire passer tous les produits de la boutique thierrytame à plaisirdelir et de fermer thierrytame
est ce possible et si oui, comment faire ?

Est-ce possible ?

car depuis le BI, je ne peux faire d'export de son inventaire, car le compte thierrytame est en particulier.

 Commentaires   
Commentaire de Fotigui Tangara [ 09/févr./09 11:14 ]
Je pense que c'est possible dans la mesure où on peut avoir une extraction de son stock.

Je te mets en PJ l'extraction de son stock (pseudo : thierrytame).

J'attends que tu confirmes l'import du fichier en PJ.

Commentaire de Jany Marimoutou [ 09/févr./09 12:24 ]
Je ne comprends pas. Tu veux que je procède à l'import du fichier sur le compte "plaisirdelir" ?

Ce fichier lrosque je l'ouvre, les éléments ne correspondent pas aux en-têtes de colonne, même après conversion dans Excel.
Commentaire de Fotigui Tangara [ 09/févr./09 13:31 ]
Non, je voulais simplement que tu jettes un coup d'¿il sur le fichier du PRO avant que je ne mette en place son format et profil.

C'est vrai qu'en ouvrant le fichier, nous pouvons constater que certains commentaires d'annonces se retrouvent dans dans la colonne "ADVERT_ID".
Nous allons essayer de traiter le fichier en ignorant les données "textes" se trouvant dans la colonne "ADVERT_ID".

Mais comme tu peux le constater, le fichier possède l'ADVERT_ID et l'EAN. Ce que je te propose, c'est mettre les annonces en place sur le compte PRO (plaisirdelir) en se basant sur l'EAN (au cas où il y en a, sinon j'essaierais de créer les annonces avec les ADVERT_ID).

Si tu le souhaite, je procède à l'import du fichier...

Commentaire de Jany Marimoutou [ 09/févr./09 13:42 ]
fait au plus simple pour toi.
mais des produits comme les disques vinyles ne possèdent pas d'EAN. L'ID product reste la seul réf envisageable pour "matcher" les éléments.
Commentaire de Fotigui Tangara [ 09/févr./09 14:02 ]
OK.
Commentaire de Fotigui Tangara [ 09/févr./09 18:02 ]
Nouveau fichier (beaucoup plus propre que le précédent).
Commentaire de Fotigui Tangara [ 09/févr./09 18:27 ]
fichier en cours de traitement
Commentaire de Fotigui Tangara [ 10/févr./09 10:55 ]
Le transfert des données s'est effectué à 95% avec 9371 annonces créées sur 9900 lignes trouvées dans le compte part (thierrytame).

Demande traitée.




[APP-24414] Oubli de création de tracking Google sur l'Espagne Création: 24/févr./09 18:14  Mise à jour: 06/mars/09 10:07  Résolue: 27/févr./09 17:38

Etat: Fermé
Projet: Application PriceMinister
Composants: Tracking
Affecte la/les version(s): 41.0.1
Version(s) corrigée(s): 42.0.0 (CTN-J)

Type: Bogue Priorité: Critique
Rapporteur: Charles Decaux Attribution: Damien Dorizy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne
Site: Prod
Projets PM: *** CHASSE ***
Classif FONC: monetisation

 Description   
Hello,

dans les trackings Google qui ont été crées dans le cadre de la migration vers keyade, le tracking 7050 LS-Google-brand a été crée sur la France, mais pas sur l'Espagne. Il faudrait le créer sur l'Espagne donc, rapidement si possible, car du coup nous ne mesurons pas les transformations liées à la marque ni sur keyade ni dans BI.

Merci

 Commentaires   
Commentaire de Charles Decaux [ 26/févr./09 11:09 ]
En fait on a refait un check avec keyade, et les tags liés à des actions d'achat sont mal posés. Tous les autres tags sont bons.
Commentaire de Fabrice Feugas [ 26/févr./09 12:50 ]
Du coup le groupe existe ou pas?
Commentaire de Charles Decaux [ 26/févr./09 13:56 ]
Il y a deux problèmes distincts :
- le tracking 7050 n'existe pas
- les tags "achat" sont mal configurés.

Merci
Commentaire de Fabrice Feugas [ 26/févr./09 16:37 ]
ok donc on créé le groupe et on traite sur l'autre JIRA pour les tags achat.
Commentaire de Damien Dorizy [ 27/févr./09 14:57 ]
Ok pour le tracking 7050 : le script est créé.
Commentaire de Charles Decaux [ 27/févr./09 16:30 ]
Merci Damien, cependant dans le BO ES je ne vois toujours pas ce code de tracking.
Sais-tu quand il sera dispo ?
Commentaire de Damien Dorizy [ 27/févr./09 17:01 ]
Avec la version CTN-J - 15 mars
Commentaire de Aurélie Kwiatkowski [ 06/mars/09 10:07 ]
Vu avec Damien, OK




[IMP-5363] Support auprès du PRO "storymode" Création: 22/févr./10 11:47  Mise à jour: 22/févr./10 11:51  Résolue: 22/févr./10 11:51

Etat: Résolu
Projet: Paramétrage - Import
Composants: Support entrant
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Fotigui Tangara Attribution: Fotigui Tangara
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: storymode
Séparateur: N/A
Type de traitement:
N/A

 Description   
Bonjour,
Société Farzad France pseudo storymode
J'ai effectué un envoi de fichier produit par le biais de votre FTP en date
du 20/02/2010 hors le changement sur notre compte price minister n'a pas été
pris en compte
Dans l'attente de vous lire
Bien cordialement
***************************************************************************************

Bonjour,

Pourriez-vous regarder pourquoi le fichier ne passe pas sur le FTP du
vendeur : storymode

Merci,

Isabelle


 Commentaires   
Commentaire de Fotigui Tangara [ 22/févr./10 11:49 ]
Bonjour,

La demande du PRO a été prise en charge sous la référence IMP-5363.

Le PRO a déposé un fichier Excel (.xls) et non CSV ou TXT.
Nous ne traitons pas les fichiers Excel.

Il suffirait qu'il convertît sont fichier au bon format, de préférence au format txt avec comme séparateur la "Tabulation" car le fichier contient 186 points-virgules. Il ne pourra plus utiliser le "point-virgule" comme séparateur de colonne au risque de provoquer des décalages de colonne lors du traitement de son fichier.

Cordialement
Equipe Import




[APP-4917] [V2] Mail activation vendeur : version spécifique pour l'auto Création: 10/juin/05 11:38  Mise à jour: 25/juin/07 18:30  Résolue: 15/juin/07 15:44

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 8.0.2b
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Stéphane Archer Attribution: Marc Cacheiro
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
*** Bug de CSW ***

Quand un compte devient vendeur par le biais d'une mise en vente AUTO il
reçoit le mail standard d'activation d'inventaire (activation vendeur) ...

Evolution : dans ce cas précis lui envoyé un mail d'activation vendeur
spécifique à l'auto => fait partie du projet (Mon compte light)

 Commentaires   
Commentaire de Quentin de Chivré [ 10/juin/05 17:54 ]
A spécifier
Commentaire de Gaël Caro [ 28/juil./06 12:25 ]
A intégrer dans chantier "Mon compte / Auto".
Commentaire de Marc Cacheiro [ 15/juin/07 15:44 ]
l'activation de l'inventaire n'est pas nécessaire pour les vendeurs auto, et le mail ne leur est plus envoyé.




[APP-32661] [POST-DEPLOY] : Gestionnaire de commande : Script de migration des item log erronés Création: 31/janv./11 16:38  Mise à jour: 08/févr./11 10:59  Résolue: 01/févr./11 18:01

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 86.0.0 (TX-R)

Type: Bogue Priorité: Mineur
Rapporteur: Emeric Teil Attribution: Yann Danot
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM: *** CHASSE ***

 Description   
Suite à la correction du bug qui créait un item log "réception implicite" alors que la transaction avait été annulée, il faudrait regarder si on ne peut pas faire un script qui permette de "récupérer" les item log créés à tort et de les remplacer par le nouveau...

NB : voir si on les "modifie" ou bien si on les "supprime" + "création" d'un nouveau... attention, aux changes dates pour le BI...

 Commentaires   
Commentaire de Julien Girardet [ 31/janv./11 18:34 ]
Actuellement nous ne récupérons pas les item log. Donc comme vous voulez pour les dates.

Julien.
Commentaire de Yann Danot [ 01/févr./11 18:01 ]
[CAJ2011Q1TX]




[BIN-613] [Back-Office] : Ajout des indicateurs "Seller claim ratio" et "Seller Cancel Ratio" dans l' univers ITEM Création: 20/juil./09 13:45  Mise à jour: 23/sept./09 12:05  Résolue: 23/sept./09 12:05

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Choses qui sont utilisées en permanence sur le BO mais pénibles à calculer à chaque fois dans BI , ce sont les taux d'annulation et les taux de réclamations.

En effet, ces deux données permettent tres simplement de visualiser un profil vendeur et dans le BI , il faut à chaque fois calculer nombre de choses et faire des requetes croisées pour les avoir.

Il serait donc fort utile d'avoir deux indicateurs dans l'univers ITEM (et user?):

- un "Seller Claim Ratio" qui retourne le pourcentage d'items avec claims accepted sur le total d'items capturés

- un "Seller Cancel Ratio" qui retourne le pourcentage d'items CANCELLED (seller_refused ou seller_time_out uniquement) sur le total d'items autorisés

Merci par avance.

Cédric.

 Commentaires   
Commentaire de Dalila Belkebir [ 23/sept./09 12:05 ]
même demande que le 550.
Demande clôturée.

Dalila.




[APP-26025] panier 100% annulé - on capture le cbv quand-même Création: 22/juil./09 15:55  Mise à jour: 17/août/09 11:34  Résolue: 27/juil./09 10:57

Etat: Fermé
Projet: Application PriceMinister
Composants: Paiement
Affecte la/les version(s): 49.0.1 (Acc. mode UK + NPF Sports & Loisirs ES + Soldes UK + Suppression HU Informatique ES )
Version(s) corrigée(s): 50.0.0 (CAT-J)

Type: Bogue Priorité: Critique
Rapporteur: Steven Harel Attribution: Arnaud Forgues
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel panier emptied + capture not null.xls     Microsoft Excel panier emptied + capture not null.xls    
Liens des demandes:
Similaire
similaire à BIN-624 [FINANCE] : Ecart GMS capturé juillet... Fermé
Pays:
FRA - France
Site: Prod
Projets PM archivés: Extensions de garanties (Lot 1) : Articles neufs

 Description   
hola !

quelques cas ce matin de personnes qui ont passé une commande en sélectionnant le cbv.
les articles du panier sont tous annulés, on devrait alors avoir une capture de 0 euros.
sur certains paniers, on capture cependant le montant du cbv !!

http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=73380742

http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=73427954

http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=73277653

 Commentaires   
Commentaire de Steven Harel [ 22/juil./09 16:59 ]
rapport bi sur les paniers "emptied" avec capture "not null" sur les 30 derniers autorisation days. on retrouve tous les cbv capturés sur des paniers annulés. il y en a 640 pour plus de 2800 euros.
Commentaire de Steven Harel [ 22/juil./09 17:16 ]
les autorisation dates de ces paniers vont du 10 juillet au 21. le problème est donc certainement toujours en cours.
Commentaire de Emeric Teil [ 22/juil./09 17:20 ]
Précision : le comportement est le même pour les EG annulées...
Commentaire de Emeric Teil [ 22/juil./09 18:00 ]
Autre précision : c'est la date de capture qui est intéressante puisqu'elles sont toutes à partir du 16/07, jour du déploiement de la TX-H... :o(
Commentaire de Steven Harel [ 22/juil./09 18:05 ]
nouveau fichier joint avec dates de capture
Commentaire de Arnaud Forgues [ 22/juil./09 18:17 ]
Y'a-t-il un rapport bi sur les paniers "partiels" avec "montant capture <> somme article commité + garantie" ?

En effet, je pense que le pb doit être le même pour tous les paniers ou certains des articles ont été annulés par le(s) vendeurs mais pas tous, et du coup on a sans doute capturé le montant des articles restants (+garanties associées) + montant des garanties des articles annulés. Mais cela est beaucoup plus transparent, car ca doit concerné princiapelement le CBV, or on communique sur le montant global CBV dans le panier.

Quoi qu'il arrive, la correction du bug prendra en compte les 2 cas !
Commentaire de Clement Balay [ 23/juil./09 14:29 ]
ok corrigé sur le tronc
Commentaire de Emilien Guichard [ 23/juil./09 14:54 ]
OK en DEV
Commentaire de Quentin de Chivré [ 27/juil./09 10:14 ]
Quid de l'historique entre V49 et V50 ?
Script de detection de ces cas ? Script de correction ? Ou correction manuelle du SAV via PMV ?
Commentaire de Steven Harel [ 27/juil./09 10:19 ]
historique traité par le sav.
nous avons traité tous les comptes du rapport bi.
+ le rapport est lancé tous les matins pour traiter les cas de la veille.
jusqu'à résolution du bug en prod.
Commentaire de Christophe Garcia [ 27/juil./09 17:45 ]
Vu par Cédric
Commentaire de Arnaud Forgues [ 27/juil./09 18:35 ]
Petit retour concernant le cas des paniers partiellement capturés : après avoir vu des exemples en PROD qui ne semblaient pas présenté le bug (exemple : http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=73349152), j'ai creusé au niveau technique et je confirme que au final, le bug n'était présent que pour les paniers totalement annulés.

Donc la manip en cours par le SAV permettra de bien gérer tous les cas impactés par ce bug.

D'autre part, j'ai vu avec la compta (Claudie), le BI (Agathe) et le SAV (Steven), il restera une incohérence au niveau de la base (à cause des paniers capturés alors que dans l'état EMPTIED), mais cela sera bien pris en compte par la compta grâce au fichier excel que tient à jour le SAV sur les remboursements en cours. De plus, une correction des données de capture provoquerait une autre incohérence d'un point de vue compta, car cela rendrait les opérations des remboursements superflues (cela aurait été possible si le remboursement avait été fait via un recredit carte depuis l'extra net SIPS)

NB : théoriquement le nombre de panier / remboursement concernés devrait correspondre à la requete suivante qui actuellement donne :
select count(purchase_id) from purchase where has_cbv = 1 and (authorization_card_amount + authorization_coupon_amount + authorization_operation_amount) <> (capture_card_amount +capture_operation_amount + capture_coupon_amount) and pch_status_code = 60 and capture_date > TO_DATE('15-07-2009', 'DD-MM-YYYY');
 ==> 1106 lignes




Finalisation installation de BO en PROD (EXP-772)

[EXP-774] Mise en place script start/stop/restart/archivelogs de l'applicatif BO sur TELLUS Création: 04/janv./06 17:49  Mise à jour: 25/juin/07 18:55  Résolue: 16/mai/07 11:03

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Mineur
Rapporteur: Sébastien Tournay Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 4 heures
Temps consacré: Non spécifié
Estimation originale: 4 heures

Liens des demandes:
Duplicate
a pour doublon EXP-775 Mise en place archivage et rotation d... Résolu

 Description   
mettre en place un mécanisme du genre pmjboss pour assurer les taches start/stop/status/archivelogs pour l'applicatif bo sur TELLUS

 Commentaires   
Commentaire de Ranto Andriambololona [ 28/mars/06 11:15 ]
François a commencé à écrire un document d'explite à ce sujet, j'attends de le recevoir ...
Commentaire de Ranto Andriambololona [ 29/mars/06 18:45 ]
Dans le document fourni par François

Démarrage BO

./ccm.sh -start all
./ccm.sh -enable all
./tomcatstartup.sh

Arret BO

./ccm.sh -stop all
./tomcatshutdown.sh

Commentaire de Ranto Andriambololona [ 30/mars/06 11:59 ]
Après analyse avec François, il s'avère que le script ccm.sh ne contient aucune variable start stop etc ..., ceux ci sont dans le fichier ccmunix.js (javascript) (/appli/priceminister/bo/bobje/setup/jscripts/ccmunix.js)

Dans ce fichier js on a pour -start

 else if (objArgs.Item(i).toLowerCase() == "-start")
            {
            //Next argument is the server type to start
            if (objArgs.Count() > i+1)
                {
                i=i+1
                serverStart(objArgs.Item(i))
                }
            }

En résumé, je pense qu'en modifiant les scirpts d'origines (en les envelloppant par pmbi --start ou autres) on risque de passer à côté de quelque chose , d'un paramètre mal connu et engendrer des disfonctionnement système.

Je pense qu'on devrait rester sur le document de base fourni par BO.

Par contre pour la rotation de log, on peut y coller le mécanisme actuel sur les SA qui déplace les vieux fichiers sur le SHARE NFS junon
Commentaire de Ranto Andriambololona [ 30/mars/06 16:47 ]
François , peux tu réfléchir si le changement du user bi en pmbi peut ètre problématique pour l'application bi ?

- L'objectif est de recréer le user bo en pmbi avec les mêmes id et gid (1527:502)
- ensuite faire un chown -R pmbi:adminpm sur les répertoires de l'appli
- tests



Commentaire de Ranto Andriambololona [ 05/avr./06 17:37 ]
On avance ....

ci -après les résultat d'une première version d'un pmbi --status, --start, --stop sur PERIGNON

STATUS

[bo@perignon bobje]$ ./pmbi --status
BI is running ( 13 processes) ...

ARRET

[bo@perignon bobje]$ ./pmbi --stop
You are about to stop BI
Type 'YES' to confirm: YES
Stopping BI ...
Using CATALINA_BASE: /home/bo/bobje/tomcat
Using CATALINA_HOME: /home/bo/bobje/tomcat
Using CATALINA_TMPDIR: /home/bo/bobje/tomcat/temp
Using JAVA_HOME: /home/bo/bobje/jdk
Stopping all...

2006-04-05 17:34:12 - [ ] BI stopped

DEMARRAGE

[bo@perignon bobje]$ ./pmbi --start
Starting BI ...
Starting all servers...

Starting pageserver...

Starting cacheserver...

Starting input...

Starting output...

Starting destjobserver...

Starting lovjobserver...

Starting reportjobserver...

Starting programjobserver...

Starting webijobserver...

Starting eventserver...

Starting ras...

Starting webi...

Starting cms...


Using CATALINA_BASE: /home/bo/bobje/tomcat
Using CATALINA_HOME: /home/bo/bobje/tomcat
Using CATALINA_TMPDIR: /home/bo/bobje/tomcat/temp
Using JAVA_HOME: /home/bo/bobje/jdk
Creating session manager...
Logging onto CMS...


2006-04-05 17:34:57 - BI started


Il reste la partie --force et l'archivage des logs
Commentaire de Ranto Andriambololona [ 11/avr./06 14:31 ]
Archivages des logs en place ...

les logs dans /home/bo/logs vieux de plus de 30 jours sont archivés (zippé et déplacé) dans

/data/priceminister/pmshare/exploit/logs/bi/ sur le SHARE NFS
Commentaire de Ranto Andriambololona [ 11/mai/06 16:29 ]
Le pmbi --stop --force est en place sur TELLUS

pour la prod, il suffit juste de copier le script pmbi (sur perignon dans /home/bo/bobje) vers le serveur bi de PROD.

Commentaire de Ranto Andriambololona [ 11/mai/06 17:41 ]
je voulais dire en place sur Perignon

Commentaire de Antoine Koener [ 19/janv./07 11:27 ]
Salut,
Dis moi ce Jira est encore ouvert, est-ce qu'on peut le fermer ?
Merci :)




[APP-29785] Problème possible sur le tag PAIEMENT REUSSI Création: 04/juin/10 11:52  Mise à jour: 30/sept./10 16:34  Résolue: 23/sept./10 11:12

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 78.0.0 (CTN-TU)

Type: Bogue Priorité: Bloquant
Rapporteur: Jonathan Gorges Attribution: Swan Desportes
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***
Classif FONC: webanalytics

 Description   
Bonjour,
Nous sommes actuellement en période de bilans et agrégeons donc les données nécessaires de nos différentes sources (Xiti, BI,...) pour sortir les résultats du mois de mai.
Nous constatons des évolutions très "louches" voir impossibles des Paiements Réussis sur plusieurs de nos canaux marketing.

Sur l'affiliation par exemple (groupe de tracking Affiliationx - Zanoxx - Cibleclickx dans Tracking 1)
-> +69% de PR (source Xiti) entre avril et mai alors que le VA augmente de +20% (source BI)
-> Cette augmentation est généralisée sur les 3 groupes de tracking (+65% sur Affiliationx, +76% sur Zanoxx, +56% sur Cibleclikx)

Sur les souhaits
Les PR ont été multiplié par 2 alors que le business des souhaits est plutôt stagnant entre avril et mai.

Sur la news culturelle
+90% de PR d'un mois sur l'autre...

Pourriez-vous svp vérifier si quelque chose a perturbé le tag PR sur mai ?

Merci d'avance pour votre aide.

Jon

 Commentaires   
Commentaire de Jérôme Viviès [ 04/juin/10 11:59 ]
Jira ouvert par erreur en DEC - je l'ai passé en app et attribué au pôle CTN sur demande de Jonathan.
Commentaire de Swan Desportes [ 04/juin/10 15:31 ]
Pour l'instant, je vois deux pistes :
- des bourdes sur la table des comptes contact. Visiblement, dans le cadre du jeu concours liste mariage, les importes de contacts ont été erratiques. Néanmoins, il ne semble pas qu'il y ait eu de comptes détruits ou réinitialisés.
- des désactivation de gros tracking. Notamment, je vois que mediastay a été désactivé ? Est ce que c'est récent ? Est ce que vous en avez désactiver d'autres ?

Merci
Commentaire de Swan Desportes [ 23/sept./10 11:12 ]
Le problème de la nouvelle page de login avec captation de l'email et donc création de contacts.
Les courbes sont très claires; On voit bien que ça concorde.

Pour palier à ce problème, un projet est prévu dans le roadmap TX pour demander aux internautes de réutiliser leurs anciens comptes plutôt que d'en créer de nouveaux.




[BIN-249] comptage des paniers et coupons sur le mail automatique M2bis Création: 19/déc./06 18:07  Mise à jour: 14/sept./07 17:33  Résolue: 19/janv./07 17:42

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Agathe,

Nous avons un pb avec l'un de nos mails automatiques proposant un coupon.
http://www.priceminister.com/newsletter/2005-01-18-auto-n2b/Encore-valable.htm

D'après les rapports que nous utilisons sur BI, nous avons 5665 coupons utilisés (code promo WELCQTZGC) et 5163 paniers (tracking 727142) issus de ce même message. Il semble qu'il y ait vraissemblablement une erreur car sur les autres messages du même type nous avons globablement 2 fois plus de paniers que de coupons utilisés.

Tu peux regarder ca ?
Merci
Alex




 Commentaires   
Commentaire de Agathe Remy [ 20/déc./06 14:49 ]
Alex,

Pourrais-tu nous communiquer le nom des rapports utilisés pour obtenir ces chiffres?

Merci:-)

Agathe
Commentaire de Alexandra Viravaud [ 20/déc./06 16:01 ]
Purchase tracking by month pour les paniers
et bilan coupon par mois pour les utilisations de coupon (dans Olivier).




[EXP-3097] minitor : manque une alerte (mod_jk) sur aricia ? Création: 18/déc./06 14:58  Mise à jour: 25/juin/07 19:00  Résolue: 24/mai/07 16:15

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Justin Ziegler Attribution: Ange Ferrari
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
on n'a jamais recu d'alerte de ce genre provenant d'aricia...

----- Message transféré ----
De : "phaeton.minitord@priceminister.com" <phaeton.minitord@priceminister.com>
À : Hostmaster Priceminister <hostmaster@priceminister.com>; Supervision Priceminister <supervisionpm@yahoo.fr>; CMS France <alertepm@infogerance.cms-france.net>
Envoyé le : Vendredi, 15 Décembre 2006, 16h40mn 15s Objet : [minitord] mod_jk reports server down (Fri Dec 15 16:40:15 2006)


phaeton Fri Dec 15 16:40:15 2006
mod_jk reports server(s) down : bi

minitord version 2.2.0

 Commentaires   
Commentaire de Justin Ziegler [ 02/mars/07 12:18 ]
Est ce que ce pb persiste ?
peut on fermer le jira ?
Commentaire de Justin Ziegler [ 02/avr./07 10:25 ]
Je constate que ce pb n'est toujours pas resolu.
Cela devient genant dans la mesure ou cupidon et phaeton vont bientot etre mis a la retraite...
Commentaire de Justin Ziegler [ 02/avr./07 10:25 ]
Quelle solution peut on envisager ?
Commentaire de Ange Ferrari [ 02/avr./07 18:06 ]
Les amis de mod_jk ont eu la bonne idée de changer le format des LOGS

Phaeton

Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=saturne failed

Aricia

(saturne) Connecting to tomcat failed. Tomcat is probably not started or is listening on the wrong port


La solution est simple c'est migré dans le nouveau système de monitoring, corrigé sur minitord le temps que les alertes parviennent aussi
à CMS depuis le nouveau systeme
Commentaire de Ange Ferrari [ 24/mai/07 16:15 ]
alerte en place




[EXP-4598] TERRA - la table PRD_EVENT n'est pas correctement alimentée Création: 30/oct./08 14:17  Mise à jour: 30/oct./08 14:25  Résolue: 30/oct./08 14:25

Etat: Résolu
Projet: Exploitation
Composants: Flux
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Bloquant
Rapporteur: Dalila Belkebir Attribution: Ayoub Benseghir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
la table PRD_EVENT n'est pas renseignée convenablement :
il y a juste les colonnes PRD_EVENT_ID et PRDUCT_ID qui sont alimentées.
Pourtant dans la base d'archive, la table semble correctement alimentée en données.


Nous devons travailler sur un projet de récupération dans le BI des données évènements sur PRD_EVENT, PCH_EVENT et WALLET_EVENT.
Merci donc de corriger l'alimentation sur TERRA de la table PRD_EVENT et de vérifier que les autres tables sont OK.

Merci.
Dalila.

 Commentaires   
Commentaire de Ayoub Benseghir [ 30/oct./08 14:25 ]
Les autres champs de prd_event étaient volontairement ignorés. Ils seront maintenant importés (prévoir une prolongation du temps d'alimentation).




[BIN-471] [Marketing] : Rapport coupon Création: 05/août/08 10:27  Mise à jour: 06/août/08 15:21  Résolue: 06/août/08 15:21

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Thomas Beylot Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello

Nous avons depuis un certain temps créé quelques nouveaux coupons. Or les rapports de coupon sur BI ne les prennent pas forcément en compte.

J'ai essayé de retoucher la requête =Si([Coupon secret name] DansListe ("ALPACINO";"CORLEONE");"PARRAINAGE";Si((Comparer([Coupon secret name];"WELC*")) OR (Comparer([Coupon secret name] secret name];"VAL*"));"AUTOMATISATION";Si(Comparer([Coupon secret name];"*AUTO*");"AUTOMOBILE";"AUTRES")))

mais devant mon manque de connaissance face à cette pbtique je me décide à faire appel à l'expert :)

merci


thomas

 Commentaires   
Commentaire de Agathe Remy [ 05/août/08 11:58 ]
Thomas,

Peux-tu nous donner le chemin d'accès et le nom du ou des rapports concernés?

Merci.

Agathe
Commentaire de Dalila Belkebir [ 06/août/08 15:21 ]
Vu avec Thomas.
La requête est donc à modifier directement dans BO.

Dalila.




[BIN-479] [Cobranding] : Arrêt du cobranding ACF au 31/08/2008 Création: 02/sept./08 11:14  Mise à jour: 14/oct./08 11:08  Résolue: 06/oct./08 16:00

Etat: Fermé
Projet: Business Intelligence
Composants: Partners
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

ACF souhaite arrêter notre partenariat. Il a pris fin officiellement le 31/08/08. Pouvons-nous activer la procédure de désactivation du cobranding ? Le JIRA est ici : http://pricejira.lan/browse/APP-21944

1 / Faire rediriger http://www.radindesbois.com/ vers PM (Exploit)
2 / Arrêter les rapports BI hebdo et mensuel (Décisionnel)
3 / Envoyer un email à tous les comptes pour leur dire qu'ils peuvent continuer à acheter sur PM (Marketing)

Souhaitez-vous faire une réunion à ce sujet ?

Ghislain


 Commentaires   
Commentaire de Agathe Remy [ 03/sept./08 15:42 ]
Rien dans le contrat : on peut intégrer nos « radin des bois » (après l'envoi d'un mail quand même, comme à chaque fois ou selon les process habituels - c'est quoi ?)

Benoit
Commentaire de Dalila Belkebir [ 03/sept./08 17:36 ]
Agathe,

1 OK => j'ai suspendu les planifications de rapports.
2 il faut donc modifier le flux PN_DATA pour les ajouter dans les BRAND_ID sélectionnés ?
3 ON peut transmettre dès aujourd'hui (ou après le mail MKT ?) les infos à MM ?
                          Juste l'info sur la fin du cobranding
                          ou aussi leur communiquer les données (et donc modifier le flux MM ?) ?

Merci de ton retour.

Dalila.
Commentaire de Dalila Belkebir [ 30/sept./08 10:30 ]
Cyril,

Voici la modification à mettre en place
- pour ce soir ou demain matin en prod sur le flux mensuel
- pour jeudi 02/10 au soir sur le flux quotidien

Dans le mapping des données pour PN_DATA, il faut :
- ajouter les anciennement co brandés "radins des bois" (ou 'ACF') dont le brand_id = 290 dans le flux mensuel
- ajouter les anciennement co brandés "radins des bois" dont le brand_id = 290 dans le flux quotidien
- tester en dev

Merci.
Dalila.
Commentaire de Cyril Tanneau [ 06/oct./08 16:00 ]
Bonjour,

les améliorations ont été apportées conformément à la demande. Les développements ont été effectués en DEV, testés et déployés en production.

Les "Radins des bois" (brand_id=290) figuraient bien dans le fichier mensuel généré le 02/10/08 ainsi que dans l'UPDATE journalier adressé à PNDATA.

Merci,

Cyril
Commentaire de Agathe Remy [ 14/oct./08 11:08 ]
Les comptes cobrandés ACF ont bien été insérés aux flux Pn Data qui se sont générés sans erreur en octobre 2008.
Agathe




[BIN-539] [Back-Office] : Demande de dimension pour les compensations Création: 07/janv./09 12:01  Mise à jour: 25/févr./09 11:59  Résolue: 07/janv./09 18:48

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Critique
Rapporteur: Cedric Favero Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
J'ai une demande un peu urgente.
Est-il possible facilement de sortir un rapport sur le nombre de compensations par virement (les anciennes) sur 2008 par date.

Je n'ai trouvé çà que dans l'univers ITEM mais on a uniquement le nombre d'items payés ou les montants.

Me faudrait donc un
- compensation count
- compensation creation date

Et est-il possible aussi de faire la distinction entre les virements nationaux et internationaux au sein de BI (car je vois simplement les type cheque, transfer et pmv) ? Par le pays?

Merci.

 Commentaires   
Commentaire de Cedric Favero [ 07/janv./09 12:01 ]
En fait c'est pour Philippe avant la fin de la semaine.
Si compliqué , je le fais à la main à partir de nos archives...

Merci.
Commentaire de Cedric Favero [ 08/janv./09 15:09 ]
Ca demande une mise en production c'est çà? Car je ne vois rien de nouveau dans l'univers en question..
Commentaire de Julien Girardet [ 08/janv./09 15:12 ]
Ca arrive bientot ! d'ici ce soir maximum.

Julien.
Commentaire de Julien Girardet [ 08/janv./09 16:22 ]
C'est bon, les nouveaux objets sont livré en Production.

Donc tu trouveras dans la classe Compensation de l'univers ITEM (France & Espagne) les objets suivant :
- Compensation creation date
- Compensation creation month
- Compensation creation year
- Compensation count

ainsi que des filtres :
- Select compensation creation date period : permet de selectionner une periode de creation de compensation
- Select compensation creation year : permet de selectionner une année de création de compensation

Concernant la distinction entre les virements nationaux et internationaux :
On peut distinguer les compensations de type virement national/ international en regardant la dimension "User bank country" (= pays de banque du virement)
Mais il n'exsite pas de type "virement international" pour les compensations
Par contre au niveau de l'opération (rattaché à la compensation) le type permet de distinguer les virements internationaux, voir la dimension Operation type label (Item/Item operation)

Peux tu valider ces nouveaux objets BO ?

Julien.
Commentaire de Agathe Remy [ 28/janv./09 20:07 ]
Bonsoir Cédric,

Peux-tu valider cette demande afin que nous puissions la clôturer?

Merci!
Agathe
Commentaire de Cedric Favero [ 29/janv./09 12:12 ]
Oui pardon, j'avais commencé mais pas fait le tour de tout.
Tout semble ok , çà fonctionne bien et plutot tres rapide.

Coté opérations PMV , je pense qu'on a ce qu'il faut , meme si plutot dans USER ACCOUNT

Merci beaucoup.




[BIN-558] [Finance] : Rapport détaillé de suivi des opérations PMV Création: 19/févr./09 10:07  Mise à jour: 16/avr./09 09:26  Résolue: 01/avr./09 11:28

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word DMR - détail des opérations PMV 1.1.doc    
Pays:
FRA - France

 Description   
Afin de permettre à la comptabilité de guider le nettoyage des opérations par le BackOffice, il est demandé de mettre en place un rapport avec le détail des opérations PMV avec la sélection d'une période de finalisation de l'opération ainsi que la sélection d'une ou plusieurs causes.
Ce rapport s'inspire du rapport Operation_Report.txt généré par l'ancien système.
Une fois le détail des opérations disposible dans BI, ne pourront être conservés dans le rapport de l'ancien système que les soldes.

Agathe


 Commentaires   
Commentaire de Dalila Belkebir [ 01/avr./09 11:28 ]
Bonjour Claudie,

Peux-tu STP vérifier et valider la demande pour clôture ?

Merci.
Dalila.
Commentaire de Dalila Belkebir [ 16/avr./09 09:26 ]
JIRA validé le 16/04 par la DAF.

Cdlt,
Dalila.




[BIN-553] [Back-office] Integration des coordonnées vendeur ? Création: 23/janv./09 09:58  Mise à jour: 24/sept./09 15:46  Résolue: 24/sept./09 15:46

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Cosmétique
Rapporteur: Cedric Favero Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Dans l'univers USER ACCOUNT, on a differentes coordonnées:

default adress
payment address
shipping address
meeting address

Mais depuis les modifs DEV faites cet été (inscription vendeur/ ouverture boutique..) , on parle maintenant de "coordonnées vendeur".
A-t-on accès à cette table ou finalement est-ce simplement l'adresse de paiement qui a été renommée?
Je crois qu'on a migré les adresses de paiement vers ces nouveaux champs mais du coup a-t-on accès à ces derniers dans le BI?

Merci.

 Commentaires   
Commentaire de Cyril Tanneau [ 28/août/09 10:31 ]
Bonjour Habib,

suite à notre entrevue de cette semaine, as-tu besoin de plus d'informations à ce sujet?

Le cas échénat, peux-tu fermer la demande?

Merci, à ta dispo si tu as des questions.

Cyril Tanneau
Commentaire de Cyril Tanneau [ 14/sept./09 16:12 ]
Bonjour,

pour revenir sur cette demande, toutes les informations relatives aux addresses sont désormais disponibles dans l'univers USER ACCOUNT, dans la classe User address.

Quant au type d'addresse analysé dans la requête, celui-ci peut être sélectionné grâce au filtre "Select user address type". (Pour les "coordonnées vendeur", il faut utiliser la RETURN ADDRESS. )

Je reste à votre disposition pour toute question.

Le cas échéant, pouvons-nous considérer cette demande comme clôturée?

merci,

Cyril
Commentaire de Habib-Sylvain Gourguet [ 24/sept./09 15:41 ]
"Les adresses, c'était mieux avant." :-)

Ok de notre côté, ce JIRA peut être fermé.

Merci.




[BIN-570] Comptage Opt-in femmes ESP Création: 17/mars/09 11:44  Mise à jour: 25/mars/09 14:22  Résolue: 17/mars/09 16:54

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Pierre-Emmanuel Bianchi Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne

 Description   
Suite à la réalisation d'un comptage des opt-in femmes en Espagne, je constate qu'il y a davantage de mails que de comptes. Or, il devrait normalement y avoir plus de comptes que de mails, car il est possible d'avoir plusieurs comptes avec la même adresse mail.

Pourriez-vous en outre m'aider concernant le problème des users birth date (beaucoup de contacts apparaissant comme étant nés en 1900...)?

Le rapport BI se trouve dans la session ur marketing (password: ant2oine), Mes dossiers/Favoris/Pierre-Emmanuel/Comptage Optin Partner.

Merci d'avance.

Cordialement,

P-E


 
 


 Commentaires   
Commentaire de Agathe Remy [ 17/mars/09 16:51 ]
Bonjour Pierre-Emmanuel,

Je viens de regarder ton rapport et voici les réponses à tes questions :
- comme expliqué par téléphone, il y a plus d'emails que de comptes dans le 2ème tableau (contrairement au 1er) parce que le contenu des colonnes est inversé : tu as l'indicateur "Subscriber email count" dans la colonne dont l'intitulé est "Subscriber count" et l'indicateur "Subscriber count" dans la colonne dont l'intitulé est "Subscriber email count";
- je ne comprends pas quel est ton problème avec les dates de naissances, surtout qu'elles n'apparaissent dans aucun des 2 tableaux. Je te propose donc de commencer par ajouter l'information puis de m'expliquer ce qui te semble incohérent.

Pour info, comme discuté avec Charles vendredi, le filtre prédéfini "Not cheater" filtre les fraudeurs mais également les comptes contacts (prospects non inscrits).
Ainsi, si tu veux les faire apparaître dans ton rapport, je t'invite à supprimer ce filtre dans la requête.

Agathe
Commentaire de Agathe Remy [ 25/mars/09 14:22 ]
Comme vu par Oral, la demande a été traitée.

Agathe




[BIN-580] [Back-Office] Univers Item - nécessité d'un Item claim creation date Création: 28/avr./09 15:31  Mise à jour: 13/mai/09 10:09  Résolue: 28/avr./09 16:21

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Cedric Favero Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Dans l'univers Item, on a bien un:

Item claim last date
Item claim closing date

=> Pb: aucune ne renvoit les claims "créées". En fait çà ne ressort que les claims acceptées, pas les rejetées..
Du coup bcp de chiffres sont biaisés et on est obligés de se rabattre sur l'item capture date mais qui malheureusement est tres éloignée du "claim date"

Il nous faudrait donc un item claim creation date (pour tout claim intervenue: créee, en cours, rejetée ....)

Merci.


 Commentaires   
Commentaire de Agathe Remy [ 28/avr./09 16:21 ]
Bonjour Cédric,

"Item last claim date" est la date de dernière ouverture de réclamation. Il existe donc des transactions avec réclamations acceptées, rejetées, en cours de traitement ou créées ET une date de dernier dépôt de réclamation.
En revanche, la dimension "Item claim closing date" étant la date de clôture de réclamation, les transactions ayant une date de clôture de réclamation sont généralement en statut définitif ("Acceptée" ou "Refusée"). Quoique si une nouvelle réclamation est ouverte sur ce même article, on aura une réclamation en statut "Crée" ou "En cours" avec une date de dernière ouverture de réclamation supérieure à la date de clôture de réclamation.

Si tu n'obtiens que des réclamations acceptées, ton problème est ailleurs...

A ta dispo si tu as des questions.

Agathe
Commentaire de Cedric Favero [ 29/avr./09 09:38 ]
Effectivement c'était mon item claim count qui ne ramenait que des claims acceptées.
Avec un item count c'est bon.

Par contre le défaut, c'est qu'une claim peut etre crée ,ouverte, fermée, réouverte lors de nos traitements et du coup çà crée un décalage.

On ne stocke pas le claim creation date c'est çà?
Commentaire de Agathe Remy [ 29/avr./09 10:02 ]
En effet, la date de 1ère ouverture d'une réclamation n'existe pas.
Il faudrait demander aux Dévs de l'ajouter.

Agathe




[DEC-332] [1euro] développement rapport décisionnel Création: 26/avr./06 18:48  Mise à jour: 14/sept./07 14:38  Résolue: 13/juil./06 17:02

Etat: Fermé
Projet: Reporting
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Martin Iacampo Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 1 jour
Estimation originale: 1 jour

Pièces jointes: Microsoft Word rapport décisionnel 1euro mini spécification fonctionnelle.doc    
Liens des demandes:
Dépendance
est bloqué par APP-8714 [1euro] développement événements Fermé

 Description   
Pour faire suite à la demande de la DG d'un rapport décisionnel, un rapport décisionnel est demandé de l'équipe BI.

Le format et contenu de ce rapport se trouve dans la pièce jointe, rapport décisionnel 1euro mini spécification fonctionnelle.doc

(Les événements seront développés et stockés dans la base, voir JIRA APP-8714.)

En cas de question, s'adresser à MIA à partir du 09/05 ou à AFO si c'est plus urgent.

 Commentaires   
Commentaire de Martin Iacampo [ 23/juin/06 14:14 ]
Mise à part un seul point (APP-10624) à étudier ultérieurement, le développement des évènements est terminé et devrait permettre le déblocage de cette demande.

**L'activation de 1euro est prévu la première semaine de juillet, et il serait top si la mise en place du rapport décisionnel suivait derrière.**

Restant à votre disposition si vous souhaitez faire un point avant de vous lancer. :-)
Commentaire de Cyrille Sarti [ 11/juil./06 16:55 ]
Bonjour,

Avez-vous convenu de la périodicité de ce rapport ?

Bonne fin d'après midi,
Annabelle.




[BIN-548] [Sponsorship] : Rapport parrainage Création: 13/janv./09 16:05  Mise à jour: 18/nov./10 18:07

Etat: Ouvert
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Thomas Beylot Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel rapport-difference-nbacheteur-filleuls.xlsx    
Pays:
FRA - France

 Description   
Hello

je viens de me rendre compte que lorsque qu'on compare les deux rapports BI sur le parrainage (dans sponsorship, les rapports nommés Referred user activity by month et Referred sponsor activity by month) les chiffres ne correspondent plus trop depuis juillet 07.

En effet je vois qu'on a plus de coupons utilisés sur les filleuls que de coupons filleuls utilisés. Or normalement les deux chiffres devraient être au moins égaux non ? il peut y avoir des filleuls actifs qui n'utilisent pas leur coupon mais à part ça je ne vois pas ce qui pourrait justifier l'écart ?

à votre dispo pour en parler, ou JM pendant que je ne suis pas là.

En pj un extract.


thomas

 Commentaires   
Commentaire de Thomas Beylot [ 05/févr./09 10:52 ]
Bonjour

a t-on du neuf sur le sujet ?


thomas.
Commentaire de Thomas Beylot [ 11/févr./09 18:27 ]
hello,

quelqu'un ?

merci
Commentaire de Dalila Belkebir [ 11/févr./09 18:30 ]
y'a personne, sont tous partis aux soldes de soldes ;-)
Commentaire de Agathe Remy [ 09/mars/09 16:52 ]
Bonjour Thomas,

J'ai quelques incompréhensions vis-à-vis de tes constats?!
- les indicateurs que tu compares (Nouveaux acheteurs et Coupons utilisés) me semblent provenir tous 2 du rapport "Referred user activity by month" et non de 2 rapports ("Referred user activity by month" et "Referral sponsor activity by month")?!
- l'indicateur "New buyers" compte le nombre de nouveaux acheteurs dont le 1er achat a été capturé et dont le tracking du panier est celui d'un des mails de parrainage;
- l'indicateur "Used coupons" compte le nombre de coupons filleuls utilisés au cours du mois

Ainsi, si tu a plus de "Used coupons" que de "New buyers" à partir d'août 2007, cela peut signifier que les 1ers achats avec coupons de parrainage proviennent moins du clic sur le mail de parrainage. Peut-être d'un couponneur? Ou bien peut-être avez-vous changé les codes de tracking des mails de parrainage en juillet 2007?

Agathe
Commentaire de Agathe Remy [ 09/mars/09 16:56 ]
Pour info, les trackings définis pour calculer les nouveaux acheteurs sont les suivants :
tracking_id;tracking_name;ust_group_id;report_period_code;creation_date;change_date
20;FILLEUL;168180;10;01/01/2001;01/01/2001
1772040;FILLEUL-relance;168180;10;06/03/2007;06/03/2007
1772041;FILLEUL-contextuel;168180;10;06/03/2007;06/03/2007
1772042;FILLEUL-contextuel-relance;168180;10;06/03/2007;06/03/2007

Agathe
Commentaire de Thomas Beylot [ 08/avr./09 09:27 ]
Hello,

Bon j'ai enfin pu me pencher sur ta réponse.
En fait tu as raison je me suis mal exprimé, je compare des datas extraites du même rapport.

Mais cela n'empêche pas que le chiffre se soit "retourné" depuis juillet 2007 (ça se confirme sur Q1 2009).

Je comprends mieux pourquoi il peut être négatif (donc que le nb de coupons utilisés dépasse le nb de nouveaux acheteurs alors que c'est illogique au départ) car je ne savais pas du tout que le nombre de nouveaux acheteurs était indexé non pas sur le suivi de l'email (sans considération aucune pour le tracking, donc) mais sur le last tracking (qui est celui du premier achat) > je suis assez étonné de ce choix, d'ailleurs, que je trouve donc illogique mais j'imagine que c'est une contrainte technique ?

Ceci étant, je me demande pourquoi la différence est positive (nb d'acheteur - nb de coupons utilisés sur les filleuls) jusqu'en juillet 07 et tout d'un coup négative depuis ? Aurait ce à voir avec la refonte du système de parrainage ? Vois tu une explication ?


thomas.




[APP-20323] Migration CBV 0-40: Probleme sur la mise à jour des montants Création: 18/avr./08 14:43  Mise à jour: 25/avr./08 11:39  Résolue: 25/avr./08 11:29

Etat: Fermé
Projet: Application PriceMinister
Composants: Base de données
Affecte la/les version(s): 20.0.0
Version(s) corrigée(s): 20.1.1

Type: Bogue Priorité: Bloquant
Rapporteur: Romain Czornomaz Attribution: Clement Balay
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Duplicate
a pour doublon APP-20365 Montant débité du PMV ne corresponde ... Fermé
Pays:
FRA - France
Site: Prod
Projets PM: *** A PLANIFIER ***

 Description   
Comme vu tout à l'heure,

Lors de la migration des données existantes en CBV interne, le montant de la prime Assur'one est passé de 0.62¿ à 0.13¿, mais la différence de ces 2 montants n' a pas été rajouté dans la Commission PriceMinister.

Il est donc nécessaire de faire un script d'update pour ajouter les 0.49¿ au montants Commission PM pour chaque CBV migré.
Lors de l'Update, il est nécessaire de mettre à jour la CHANGE_DATE des enregistrements à SYSDATE afin que nous puissions prendre en compte les changement au BI.

Merci d'avance,

Romain


 Commentaires   
Commentaire de Sébastien Aubert [ 21/avr./08 12:14 ]
Script passé en integ --> Ok les garanties (internal) créées avant le 08/04/2008 à 10h56 ont eu 0.49 ¿ ajouté à leur com interne .

Problème restant sur l'évenement :
L'évenement doit être "Migration Corrective" et la descritpion doit être "Commission interne + 0.49"
Commentaire de Juan Luis Fajardo [ 24/avr./08 10:19 ]
Panier 56852111

Est-il possible de corriger le montant?
Commentaire de Sébastien Aubert [ 25/avr./08 11:29 ]
Le script est passer hier en prod et a corrigé les paniers concernés.




[Metatache CBV2] Implémentation de CVB V2 (APP-17836)

[APP-18098] [CBV - V2] Changement de l'état "retracted" d'une garantie Création: 02/oct./07 16:37  Mise à jour: 19/oct./07 14:44  Résolue: 04/oct./07 19:12

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 17.0.0
Version(s) corrigée(s): 17.1.0

Type: Sub-improvement Priorité: Majeur
Rapporteur: Renaud Dierickx Attribution: Renaud Dierickx
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM archivés: Contrat "Bris et Vol" (Lot 2)

 Description   
Demande de Steven :
"on doit pouvoir revenir sur une rétractation. non pas pour revenir sur la décision de l'acheteur (c'est définitif) mais pour corriger une erreur d'un agent back office. L'état "retracted" s'il est définitif doit être intégré au rapport du bi pour remboursement pas assur'one. ça serait plus prudent d'utiliser les mêmes critères de temps que pour le "refunded" : si pas bougé au bout de trois mois"

Je ne peux pour le moment pas faire ce développement car j'ai besoin du dev d'AFO qui est sur la branche V17_0_0.
Ce jira me sert de mémo pour ne pas oublier de faire la demande de steven dès que possible.

 Commentaires   
Commentaire de Sébastien Aubert [ 19/oct./07 14:44 ]
ok en integ




[APP-19807] Pb adresse dans "Mail à un ami" Création: 03/mars/08 10:53  Mise à jour: 16/avr./08 11:27  Résolue: 05/mars/08 10:13

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 19.0.3
Version(s) corrigée(s): 20.0.0

Type: Bogue Priorité: Majeur
Rapporteur: Christophe Garcia Attribution: Renaud Dierickx
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg     JPEG File screenshot-1.jpg    
Pays:
FRA - France
Projets PM archivés: Maintenance 20.x.x

 Description   
Quand on envoie un mail à un ami, on va en base chercher le login de l'ami en fonction de l'email qui a été saisi.
Pb : En revanche, on devrait essayer de trouver le compte le plus récent associé à cet email : en utilisant la "last_login_date" - c'est ce que fait le BI pour les mails MM (à vérifier avec eux)

Exemple :
http://bo.priceminister.com/user_back?action=userview&showeventothers=true&useraccountid=61114
 
 


 Commentaires   
Commentaire de Renaud Dierickx [ 03/mars/08 11:03 ]
Etes-vous d'accord avec cette solution fonctionnelle ?
Commentaire de Quentin de Chivré [ 03/mars/08 18:45 ]
Ben oui c'est moi qui l'ait donnée :-)
Commentaire de Renaud Dierickx [ 05/mars/08 10:13 ]
Parfait ! C'est corrigé.
Cette fonctionnalité utilise un finder qui est également utilisé à d'autres endroits du site qui n'ont pas besoin du order by : les abo, l'inscription, ...
Pour éviter les régressions au niveau des performances, j'ai créé un nouveau finder.




[APP-20055] Regression 19.2.1. Certains évènements annonces ne sont plus créés. Création: 31/mars/08 15:35  Mise à jour: 25/avr./08 09:35  Résolue: 21/avr./08 11:04

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 19.3.0
Version(s) corrigée(s): 19.4.0

Type: Bogue Priorité: Critique
Rapporteur: Edouard Gomez-Vaez Attribution: Manuel Sadok
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel APP-20055-done.xls     Microsoft Excel count_adv_event.xls    
Pays:
FRA - France
Classif1: BP
Classif2: trigger best-price
Projets PM archivés: BP - Consolidation Produit / Annonce

 Description   
Extraits d'une analyse BI.

Voici les 4 évènements qui ne sont plus créés de puis le 26/03/2008 :
280 FRESHNESS_INFO
290 FRESHNESS_WARN
300 FRESHNESS_OUTDATED
410 PENDING_PUBLICATION

Les évènements suivants sont aussi susceptibles d'être touchés, mais comme ils ont des volumétries très faibles, nous ne pouvons en être sûrs :
155 CLOSE_FROM_BO_MACRO_PRODUCT
500 PENDING_CONTRACT


 Commentaires   
Commentaire de Manuel Sadok [ 01/avr./08 11:50 ]
Ces 6 évènements sont de nouveaux générés.
Commentaire de Espérance Galouo-Lece [ 04/avr./08 11:00 ]
Done.




[APP-21554] Raccourcis NpC : niveau 1 vers niveau N-X Création: 30/juil./08 18:16  Mise à jour: 24/sept./08 18:27  Résolue: 24/sept./08 17:06

Etat: Fermé
Projet: Application PriceMinister
Composants: Référencement
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 30.0.0 (CAT-D)

Type: Amélioration Priorité: Critique
Rapporteur: Thierry Leforestier Attribution: Caroline Schinzel
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File illustration de la demande.jpg     PNG File raccourcis.png    
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***

 Description   
Aujourd'hui, l'application permet d'effectuer des raccourcis par le biais de l'option "afficher les fils", mais ne permet pas d'obtenir une finesse sur le choix des catégories ou sous catégories a remonter en raccourcis.

il faudrait donc qu'une option "raccourcis" soit disponible dans le BO sur le noeud concerné pour ajouter manuellement un raccourci (par option) avec la liste des sous catégories dans un select.

une fois sélectionné, ce noeud apparait sous la catégorie (voir PJ).

N'hésitez pas en cas de question

 Commentaires   
Commentaire de Thierry Leforestier [ 30/juil./08 18:17 ]
Cette modif doit être dispo surtout pour l'espagne (dans le cadre du chantier optimisation Nav Par Cat)
Commentaire de Benoît Bourdon [ 31/juil./08 10:16 ]
Ce que je comprends de la demande :
1- Actuellement on peut faire des raccourcis d'un niveau N à N-1 et c'est tout
2- On ne peut pas faire de raccourcis vers 1 seule sous-cat mais vers toutes les sous-cat "soeurs" en même temps

---> Cette evolution sera uniquement appliquée pour l'Espagne (qui va rester encore longtemps en NPC et qu'il faut optimiser d'un point de vu REF sans attendre les futures NpF)
(je remet le contexte, car il n'était pas prévu de retoucher un jour la NpC .. il était plutôt prévu de la laisser mourir tranquillement ...)

--> Le but donc permettre la création de raccourcis (à peu de frais) à partir d'un noeud donné :
 - Vers n'importe quelle sous catégorie (une par une) de n'importe quel niveau de profondeur
 - Ces liens seront fait uniquement pour les apsects référencement -> il seront systématiquement crawlable (ie : on ne rajoutera pas un paramètre brouillable oui / non)

Commentaire de Benoît Bourdon [ 31/juil./08 10:17 ]
PS : il faut utiliser le style existant pour les raccourics (pas besoin de maquettes)
Commentaire de Martin Sudmann [ 25/août/08 15:11 ]
Je reviens sur le "à peu de frais":

la solution bon marché serait de régler ça via des paramètres dans la conf ; seul bémol : on ne peut pas varier l'ordre d'affichage.
On peut appliquer un tri automatique (par ordre alphabétique, par exemple), mais si on a "otras" et "zorro", "otras" viendrait forcement en premier.

Thierry, pourrais tu voir avec les commerciaux / les params si c'est ok pour eux ?
Si le dev devient plus complexe que ça, le Jira sortira probablement de la CAT-D.
Commentaire de Thierry Leforestier [ 25/août/08 15:30 ]
C'est validé avec les commerciaux, l'ordre d'affichage ne leur pose pas de problème.

D'autant que nous ne ferons que très rarement ressortir otros a mon avis, le tri, quel qu'il soit, restera donc globalement pertinent.

Thierry
Commentaire de Martin Sudmann [ 25/août/08 16:35 ]
ok, l'implémentation sera donc à priori:

un paramètre sur le noeud parent NpC permet de pointer sur une autre catégorie NpC pour la remonter en tant que sous catégorie.
L'ordre des catégories remontées sera dans tous les cas l'ordre alphabétique et n'est pas, comme dans les vraies sous-catégories, configurable.
Les liens remontés seront toujours crawlables, puisque c'est une demande du référencement.
Commentaire de Martin Sudmann [ 29/août/08 16:31 ]
j'ai regardé un peu ; grâce au sublime code de la NpC (bien structuré et maintenable; je rigole.) ce n'est pas facile à implémenter.
Je le transfère à MOD, mais ne ne peux pas garantir que ça passe en cat D.
Commentaire de Martin Sudmann [ 29/août/08 16:31 ]
voir si c'est faisable sans trop dégrader le code (même si c'est la NpC ; il faut quand même la garder maintenable).
Commentaire de Caroline Schinzel [ 19/sept./08 11:41 ]
L'implémentation est bien celle décrite par Martin un peu plus haut (25 août - 16h35)
Les sous-catégories remontées s'affiche à la suite des fils du noeud parent s'ils sont affichés (Combinaison d'affichage des deux modes de remontée)
Commentaire de Benoît Bourdon [ 19/sept./08 11:47 ]
Cool :-)
Je peux tester quelque part et montrer ça au Ref ?
Commentaire de Christophe Garcia [ 24/sept./08 16:40 ]
Aucune vérification n'est faite sur le fait que l'on pointe bien vers une sous-catégorie.

Voir URL : http://www.es.integ/navigation/default/category/root_games

Le lien Bateria n'est pas une sous-cat de Consolas
Commentaire de Martin Sudmann [ 24/sept./08 17:06 ]
le développement a été demandé en tant qu'implémentation LIGHT.
La solution choisie (et donc la possibilité de pointer vers d'autres sous catégories) a été discuté et acceptée par le BO.
Les référencement est conscient qu'il faut faire attention de bien choisir le lien sur lequel ils pointent.




[APP-24987] Fiche sinistre : le passage à l'état "Remboursé" ne fait rien Création: 17/avr./09 17:12  Mise à jour: 28/juil./09 10:27

Etat: Ouvert
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Marc-Antoine Decreton Attribution: Steven Harel
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM: *** CHASSE ***

 Description   
Sur l'écran de détail d'un sinistre, il est possible de changer l'état du sinistre.
Le passage à l'état "Remboursé" ne fait absolument rien.

J'ai modifié ce comportement en affichant le message suivant : "Le passage du sinistre dans l'état Remboursé n'est pas possible en mode manuel" (voir APP-24897).
Aujourd'hui, le passage à "remboursé" ne se fait que par le biais de batchs qui effectuent des actions supplémentaires (crédit sur le PMV, envoi de mail à l'utilisateur...).

Doit-on garder le comportement actuel (interdire le passage manuel à "Remboursé"), ou effectuer une autre action ?

 Commentaires   
Commentaire de Emeric Teil [ 29/mai/09 11:02 ]
Cedric, un avis la dessus ?
Commentaire de Cedric Favero [ 02/juin/09 18:29 ]
Je regarde çà, çà me parle pas vraiment.
Commentaire de Emeric Teil [ 27/juil./09 09:49 ]
Du nouveau ?
Commentaire de Cedric Favero [ 28/juil./09 10:03 ]
A confirmer avec Steven mais effectivement ne sert à rien de conserver l'état "remboursé" dans le menu de selection manuelle si la seule façon d'arriver à un état remboursé correct est apres le passage d'un batch.
suffit donc de supprimer cet état de cette liste.
Commentaire de Emeric Teil [ 28/juil./09 10:05 ]
OK merci ! Steven, ok avec ça ?

NB : techniquement reste à voir si cela est possible...


Commentaire de Steven Harel [ 28/juil./09 10:27 ]
on peut garder le comportement actuel. pas utile de modifier quoi que ce soit.




[APP-28650] [LPS] Mauvaise initialisation du formulaire de Mev Création: 09/mars/10 11:38  Mise à jour: 04/mai/10 09:48  Résolue: 17/mars/10 14:46

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 63.0.3
Version(s) corrigée(s): 68.0.0 (VEN-B)

Type: Bogue Priorité: Majeur
Rapporteur: Jean-Sébastien Franck Attribution: Jean-Sébastien Franck
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à APP-28739 [LPS] Pas de page de retrait après mo... Fermé
Pays:
FRA - France
Projets PM: MEV - Landing Page Scénarisée
Navigateur: Tous

 Description   
Lorsqu'on est sur la proposition d'amélioration d'annonce, toute modification de la FP par le biais du lien "modifier l'annonce" est prise en compte en base de données, mais lorsqu'on re-modifie l'annonce, on retrouve les anciennes valeurs dans le formulaire.

Pour reproduire le bug :

1) Créer un produit de type vêtement. On se retrouve sur la LPS avec une proposition d'amélioration d'annonce.
2) Cliquer sur "modifier l'annonce" (le lien bleu), changer des champs (par exemple la taille et le commentaire) puis valider la modification pour retourner sur la LPS
3) Cliquer sur "modifier l'annonce" et constater que les champs ont leurs anciennes valeurs et non pas les valeurs qui ont été modifiées en 2)


 Commentaires   
Commentaire de Jean-Sébastien Franck [ 17/mars/10 14:46 ]
Les données du formulaire de mise en vente n'étaient pas correctement insérées en session. Problème corrigé.




[APP-15148] Activation de l'inventaire lors d'une mise en vente auto? Création: 16/févr./07 16:26  Mise à jour: 25/juin/07 18:49  Résolue: 12/avr./07 18:37

Etat: Fermé
Projet: Application PriceMinister
Composants: Annonces, Inventaire
Affecte la/les version(s): 12.0.2
Version(s) corrigée(s): 14.0.0

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Marc Cacheiro
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod

 Description   
Lorsque l'on crée un compte et que l'on met une voiture en vente , on dispose bien d'une annonce visible dans l'espace "vendeur auto" et mes annonces auto en ligne mais pourtant l'inventaire n'est toujours pas actif et on ne peut donc accéder directement à son annonce par ce biais.

On a toujours le message "pas encore vendeur" et aucune rubrique dispo en dessous d"espace vendeur" dans la colonne de gauche.

Si le fait de passer une annonce auto met le compte en visiblité 1 (est-ce bien le cas?) , l'inventaire ne devrait-il pas etre activé dans la foulée?

 Commentaires   
Commentaire de Patrick Condevaux [ 16/févr./07 18:13 ]
Dans ce cas, les annonces auto sont accessibles dans la rubrique Mes annonces Auto en ligne
dans la catégorie Vendeur Auto
Commentaire de Nicolas Chauveau [ 26/févr./07 10:44 ]
Est-ce le comportement prévu ou une amélioration ?
Commentaire de Marc Cacheiro [ 12/avr./07 18:37 ]
l'inventaire auto est spécifique, pas besoin de l'activer pour faire apparaître les annonces...




[APP-19665] [Mots clés / Surveillance vendeur] Dectection du numéro de compte renseigné avec velocity? Création: 19/févr./08 16:52  Mise à jour: 02/juin/09 16:51  Résolue: 08/avr./09 12:10

Etat: Fermé
Projet: Application PriceMinister
Composants: Back-Office
Affecte la/les version(s): 19.0.1
Version(s) corrigée(s): 47.0.0 (TX-G)

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Dispatcher (Pôle TX)
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File rib.JPG     JPEG File screenshot-1.jpg    
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***
Classif FONC: CoSAV

 Description   
Afin de mieux pouvoir retrouver des fraudeurs récidivistes , il nous serait utile de pouvoir surveiller en velocity le numéro de compte renseigné par un utilisateur.

En effet , une personne essayant à de nombreuses reprises de faire des ventes frauduleuses a de fortes chances pour se faire payer de renseigner à chaque fois le meme numero de compte.

Est-il possible d'appeler en velocity des données du USR_BANK_ACCOUNT ? Essentiellement le numéro de compte du vendeur (capture).

Le but étant de faire passer en -1 celui qu'on aura détecté par ce biais (surveillance vendeur).


 Commentaires   
Commentaire de Geneviève Beaujard [ 04/mars/08 16:32 ]
rien a voir avec les produits, renault STP peux tu renseigner cedric.
Commentaire de Emeric Teil [ 27/mars/08 18:51 ]
A prendre en compte dans les besoin de mot clefs pour l'Automatisation ?
Commentaire de Cedric Favero [ 28/mars/08 09:12 ]
pour moi il s'agit plus de detecter des fraudeurs récidivistes par leur numero de compte (detection et passage du compte en -1)

mais je vois avec steven si c'est egalement un besoin concernant l'automatisation des opérations de débit.
Commentaire de Emeric Teil [ 28/mars/08 09:55 ]
En fait je pensais que, si on a des coordonnées bancaires qui nous permettent de détecter des fraudeurs, il serait potentiellement un plus de les ajouter également au niveau des bordereaux afin de mettre systématiquement les opérations correspondantes en Observation.

De plus, au niveau des opérations cela ne nous "coute pas très cher" car :
-> L'objet "opération" sera dans le contexte velocity"
-> Les coordonnées de paiement sont inclues dans l'opération depuis la Centralisation du PMV (avant elles étaient incluent dans l'utilisateur)
-> On aura donc les coordonnées utilisées pour l'opération dans le contexte velocity utilisé pour les mots clefs sur les bordereaux

Commentaire de Cedric Favero [ 28/mars/08 10:15 ]
je mets steven en copie
Commentaire de Cedric Favero [ 23/mai/08 10:18 ]
Demande intégrée dans le projet automatisation des opérations de débits , il est possible de surveiller des informations bancaires avec la table opération (surveillance debits).

Par contre ma demande initiale concernait les surveillance vendeur , et il me faudrait donc pouvoir , pour ce type de mot clé, acceder en velocity à la table USR_BANK_ACCOUNT

Merci.
Commentaire de Emilien Guichard [ 02/avr./09 18:17 ]
Quelles sont les coordonnées bancaires auxquelles on doit donner accès, celles de débit, celles de crédit ou les 2 ?
Commentaire de Cedric Favero [ 03/avr./09 09:08 ]
Celles de débit suffisent.
Ca peut etre le RIB, l'IBAN ou encore l'adresse postale du cheque.
Commentaire de Clement Balay [ 07/avr./09 12:16 ]
En fait les infos étaient déjà présentes, nous avons quand même rajouté deux méthodes pour simplifier leurs accès:

a partir d'un objet Operation, vous pouvez récupérer un objet AddressFormat ou BankAccountFormat de cette manière:
- $operation.getAddressFormat()
- $operation.getBankAccountFormat()

A partir de là pour récupérer l'adresse formattée vous pouvez faire:
- $operation.getAddressFormat().getFullFormatedAddress()

Pour récupérer le code postal:
- $operation.getAddressFormat().getStrZipCode()

Pour récupérer le compte banquaire formatté:
- $operation.getBankAccountFormat().getFormatedBankAccount()

Pour récupérer l'IBAN
- $operation.getBankAccountFormat().getIban()

Pour récupérer le RIB
- $operation.getBankAccountFormat().getRibAccountNumber()
Commentaire de Cedric Favero [ 07/avr./09 12:20 ]
Ok sauf que pour la surveillance vendeur c'est dans le contexte $user qu'il me les faut..
$operation , ce n'est que lors d'un crédit/débit.
Commentaire de Clement Balay [ 08/avr./09 12:10 ]
Ok, done,
De plus j'ai rajouté l'outil de visualisation du contexte velocity pour le mot clé "surveillance vendeur" dans la page annonce, comme cela tu pourras voir un nouvel objet: bankAccount
Commentaire de Cedric Favero [ 08/avr./09 16:28 ]
Je peux voir où à quoi çà ressemble?
Commentaire de Clement Balay [ 10/avr./09 16:37 ]
sur devtest1
Commentaire de Emilien Guichard [ 15/avr./09 09:59 ]
Recette OK en DEV




[IMP-6754] ALIBRIS: confcall avec commerciaux Création: 13/août/10 11:32  Mise à jour: 13/août/10 14:31  Résolue: 13/août/10 11:34

Etat: Résolu
Projet: Paramétrage - Import
Composants: Demande commerciale
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Laurent Payot Attribution: Laurent Payot
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Login: ALIBRIS
Séparateur: N/A
Type de traitement:
N/A

 Description   
Confcall de 17h à 18h30 avec les IT de ALIBRIS. Le pro qui agrège diffèrents partenaires (un peu comme neteven) à 160 Millions d'annonces, et dans certaines périodes critiques comme Noël jusqu'à 35% des annonces peuvent être mises à jour quotidiennement (prix).

Compte tenu des limitations techniques en termes de volume de traitement il faudra repartir les annonces du pro sur différents comptes, et limiter le nombre d'annonces total. Malgré tout pour l'instant le partenaire est trop gros pour être intégré, les commerciaux vont voir les différentes possibilités avec Justin. Une quantification de la capacité de traitements des imports va être effectuée par Fotigui en utilisant le BI.

 Commentaires   
Commentaire de Laurent Payot [ 13/août/10 14:31 ]
De : Jeremy Pallot [mailto:jeremy.pallot@priceminister.com]
Envoyé : vendredi 13 août 2010 14:41
À : 'Pam Nice'; 'Gael Seguillon'
Cc : 'Brian Elliott'; 'Dave Rees'; 'Laurent Payot'; 'Jérôme Viviès'
Objet : RE: Notes: PriceMinister and Alibris, August 12, 2010

Hello Pam,

It was really nice talking to you yesterday. I am glad that could have such a productive conversation.

I have upgraded your Uk account to the professional status.

I confirm that all the summary of yesterday's phone call are accurate.

ACTIONS and NEXT STEPS:
¿ ACTION: PriceMinister to estimate catalog file size to Alibris. Pam to set up FTP. PriceMinister to provide Alibris with Google Feed for catalog.
Laurent will come back to you on the catalog maximum authorized size per FTP.
Gaël/Myself will come back to you in regards to the Google feeds. It may take a up to a week.
¿ ACTION: PriceMinister to make recommendation to Alibris on the optimal account configuration:
o Number of accounts.
o Max # of listings per account.
o Max and recommended file sizes for upload, adds, deletes, updates.
Laurent will come back to you in regards to all the FTP performance indicators.
¿ ACTION: PriceMinister to send a shipping file with standard shipping prices, methods, and times.
Please find enclosed the shipping cots refund grid per country. The values in red are what is paid by the customer and the values in black are what is refunded to the pro seller.
¿ ACTION: Pam to set up test account at PriceMinister. Jeremy will be the primary account manager contact with Laurent supporting. Note: we may use standard seller agreement, or, if necessary, request a custom contract.
I will be your account manager and Laurent your IT support. On the legal side we are open to both solutions, you can on our Uk site read our general conditions. If you need a customized contract, I will ask my legal team to contact you.
¿ ACTION: Pam to arrange follow up meeting for next Thursday, 7PM Paris time, 30 mins so we can see how things are progressing.
I will be next week out of the office on a business trip and can therefore not attend the meeting. Would it possible to postpone the meeting in two weeks?

I remain at your disposal if you have any questions.

Kind regards,

Jeremy

PriceMinister.com
Jérémy Pallot
Key Account Manager Northern Europe
57 Bvld de la Villette
F- 75010 Paris
France
jeremy.pallot@priceminister.com
Tel : +33 (0) 1 42 78 95 48
Fax : +33 (0) 1 42 72 80 61
UST: FR23432647584

De : Pam Nice [mailto:pamn@alibris.com]
Envoyé : jeudi 12 août 2010 19:43
À : 'jeremy.pallot@priceminister.com'; 'gael.sequillon@priceminister.com'
Cc : Brian Elliott; Dave Rees
Objet : Notes: PriceMinister and Alibris, August 12, 2010

Hi Everyone,

Thank you so much for the informative call, and your patience with the phone system issues. My notes are below - please forward to Laurent as I don't have his email address. I'm hoping you can check the notes for accuracy. We'll be moving forward on the action items, and look forward to talking to you again next week.

I'm copying Dave Rees, my project management lead, as he will be assisting on the program.

Best regards,
Pam


============================================================================
Notes: PriceMinister and Alibris, August 12, 2010
Attendees: Jeremy Pallot, Gael Seguillon, Laurent, Brian Elliott, Pam Nice
============================================================================

Opportunity:
¿ Alibris would like to list and sell its seller inventory on PriceMinister's UK, FR, and ES sites.
¿ Alibris will pass inventory and orders via data replication, as we do on Half, Ebay, and Buy.com today.
¿ PriceMinister's current sales volume is 4m books/year but they're growing.
¿ They expect we could sell 50k-60k orders per month on their properties.
¿ Rakuten is funding additional staffing in UK and ES so sales are expected to increase on those sites quickly.

Inventory:
¿ PriceMinister supports several inventory management processes:
o Upload, for all items that are already in PriceMinister's catalog (their catalog is also referred to as "standard reference").
o Catalog item creation process.
o Adds.
o Deletes.
o Skinny update, SKU+price change only: does not exist today but PriceMinister will build it for Alibris.
o Reconciliation file creation: weekly, currently manual but will automate - this will be functional in one month.

¿ Inventory files:
o PriceMinister doesn't enforce limits on the number of listings, but there are file size constraints.
o Max recommended size is about .5m items which can take 10 hours to process.
o A file with 1.2m lines can take up to 24 hours to process.
o Processing for small files for adds, deletes, updates is very fast.
o They do not prioritize processing based on file size; it's simply first-in-first-out.
o Yes, PriceMinister systems will let us list non-ISBN items, via the Catalog item creation process. Requires unique Alibris SKU.
o Yes, we can list multiple copies of a single ISBN, even if they are in the same condition, within a single account, as long as SKU is unique.
o Different currencies: Alibris will create separate pricing columns for each currency, all in a single inventory listing file.
o

Structuring the accounts on PriceMinister:
¿ Alibris can support the following inventory management configurations:
o Multiple accounts containing many sellers.
o "Vanity" accounts where Alibris manages seller accounts for them.
o A combination of the above.
¿ Alibris will probably want to have UK/EU sellers in separate accounts so that the ship times can be faster for those sellers.

Orders:
¿ Each account will have a dedicated server. Orders will appear in a folder "Purchase".
¿ PriceMinister must receive order confirmation back within 48 hours (2 business days).
¿ PriceMinister auto-cancels the order after 3 days.
¿ PriceMinister supports customer cancels. Alibris does not support these - they will have to be handled as refunds.

Shipping:
¿ UK price must include the shipping uplift as they require free shipping in the UK. For FR and ES, shipping costs are set by Alibris.
¿ Ship-time commitments are set by Alibris in the storefronts.
¿ Ship time from Alibris' US sellers to Europe can be 45 days due to a two-leg process with consolidation. This is OK as long as we set this expectation with the customer in our Storefront.
¿ While PriceMinister supports multiple shipping types, Alibris need only support standard shipping.
¿ Alibris will probably want to have UK/EU sellers in separate accounts so that the ship times can be faster for those sellers.

Returns and refunds:
¿ PriceMinister absorbs most returns, including cases where the item was not as expected.
¿ The return instructions will tell the customer to return the item to a PriceMinister address.
¿ PriceMinister pays Alibris, then re-sells the items themselves.
¿ In cases where the customer says they never received the item, PriceMinister sends a standardized email to Alibris. Alibris must respond in 72 hours. The FR and ES emails are translated.
¿ PriceMinister supports customer cancels. Alibris does not support these - they will have to be handled as refunds.

Payment:
¿ Payment occurs every 10 days (3x/month), on the 1st, 10th, and 20th day, if the sale is "confirmed" (if the customer left feedback on the sale).
¿ If the customer hasn't left feedback on the sale, Alibris will be paid on the 20th of the following month. The average payment delay is 11 days.
¿ There are no currency concerns surrounding payment, because Alibris sets the price and does the currency conversion in the inventory listing files.
¿ Each site will pay Alibris with a separate bank transfer.

ACTIONS and NEXT STEPS:
¿ ACTION: PriceMinister to estimate catalog file size to Alibris. Pam to set up FTP. PriceMinister to provide Alibris with Google Feed for catalog.
¿ ACTION: PriceMinister to make recommendation to Alibris on the optimal account configuration:
o Number of accounts.
o Max # of listings per account.
o Max and recommended file sizes for upload, adds, deletes, updates.
¿ ACTION: PriceMinister to send a shipping file with standard shipping prices, methods, and times.
¿ ACTION: Pam to set up test account at PriceMinister. Jeremy will be the primary account manager contact with Laurent supporting. Note: we may use standard seller agreement, or, if necessary, request a custom contract.
¿ ACTION: Pam to arrange follow up meeting for next Thursday, 7PM Paris time, 30 mins so we can see how things are progressing.




[CAT-3471] Liste des Tracking de la plateforme Zanox Création: 21/janv./11 11:28  Mise à jour: 25/janv./11 09:39  Résolue: 25/janv./11 09:39

Etat: Résolu
Projet: Paramétrage - Non Import
Composants: Outils internes / Rapport
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Remigiusz Woronkiewicz Attribution: Rocio Perez-Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Classif CAT: Affiliation

 Description   
Bonjour,

Pour faire un état des lieux de nos trackings chez Zanox j'aurais besoin de toute la liste des codes de tracking qui remontent bien chez nous pour les 2 groupes de Trancking : Zanoxx et Zanoxx-Cashbacker (1 variable "VA" en plus dans le tag).
En effet, j'ai besoin de savoir si les codes rentrés dans le Back-Office remontent bien en prod et dans BI, et ceci pour éviter toute perte de tracking.

Rocio avait déjà fait cet extract pour Effiliation donc elle devrait être en mesure de le faire pour Zanox.

A votre disposition pour toute question.

Merci d'avance !

Rémi

 Commentaires   
Commentaire de Rocio Perez-Garcia [ 24/janv./11 14:44 ]
Salut, voici la liste de trackings selon le type de tag:

 - Zanox first buy, buy et 1a MeV:
1544040,1748140,1748141,1748042,2173340,2173341,2173342,1879141,2227466,2227467,2227468,2227469,2227470,2227471,2227472,2227473,2227474,2227475,2227476,2227477,2227478,2227479,2237151,2237152,2237153,2237154,2237155,2237156,2237157,2284845,2284846,2284847,2284848,2284849,2284340,2300345,2300346,2300347,2300348,2300349,2318940,2318941,2318942,2318943,2318944,2337957,2337958,2337959,2337960,2337961,2337962,2337963,2337964,2337965,2337966,2337967,2337968,2337969,2337970,2337971,2337972,2337973,2337974,2337975,2337976

 - Zanoxx_cashbackers_Buy:
2318940,2318941,2318942,2318943,2318944

 - Zanoxx_oldcashback_buy:
2227469,2227477
Commentaire de Remigiusz Woronkiewicz [ 24/janv./11 14:49 ]
Salut Rocio,

Merci pour ton aide.

Bonne journée!
Rémi




[APP-32585] Marquer les messages reçus par "WS Post-vente" Création: 25/janv./11 18:01  Mise à jour: 25/janv./11 18:01

Etat: Ouvert
Projet: Application PriceMinister
Composants: Back-Office, Mails
Affecte la/les version(s): 86.0.0 (TX-R)
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Habib-Sylvain Gourguet Attribution: Dispatcher (Pôle TX)
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM: WS GetToDoSeller

 Description   
En BO, dans les pages à partir desquelles il est possible de consulter les messages reçus (fiches user, article, panier...), permettre de distinguer un message reçu via WS d'un message reçu via formulaire classique en FO.

Version classe : rajouter un picto à côté des titres des messages sur ces différentes fiches.

Version du pauvre : ajouter une ligne dans la popup de visualisation du message et écrire "... (via Web Service)".

Marquer les messages reçus via WS permettrait peut-être aussi de récupérer l'info dans BI pour plus facilement (et mieux) analyser les résultats du projet "WS Post-vente".




[APP-23422] KPI recyclage Création: 02/déc./08 09:41  Mise à jour: 01/sept./09 14:27

Etat: Ouvert
Projet: Application PriceMinister
Composants: Annonces
Affecte la/les version(s): 35.0.1.2, 52.0.0 (CTN-M)
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Thomas Beylot Attribution: Dispatcher (Pôle CTN)
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Site: Prod
Projets PM: *** RESERVE ***
WishList: Marketing
WishList - Complexité: H
Classif FONC: webanalytics

 Description   
Bonjour,

Nous souhaiterions pouvoir suivre le nombre d'annonces provenant du recyclage. Du coup il faudrait poser un flag de sorte à ce que nous puissions sortir l'info notamment grâce à BI.

En effet, nous allons mettre en place une action crm invitant les acheteurs à mettre en vente les produits listés dans leur listing "revendez vos achats". Ce chiffre nous permettrait de savoir si oui ou non elle a un impact pour envisager de communiquer de façon plus large sur la fonctionnalité.


merci,


Thomas.

 Commentaires   
Commentaire de Swan Desportes [ 03/déc./08 11:29 ]
Il s'agit d'une modification de base de données dans le cadre de la mise en vente --> pôle CAT
Commentaire de Benoît Bourdon [ 05/août/09 14:52 ]
... désolé de te le renvoyer :-)
il me semble que recyclage fait parti des transfo pour le nouveau plan de marquage xiti.

--> Jira à fermer à la sortie de la CTN-M ?

(par ailleurs ça me semble plus propre de faire ça via un outil de webanalytics plutôt que d'ajouter une info en base sur les annonces ...)
Commentaire de Swan Desportes [ 01/sept./09 14:27 ]
A traiter après la mise en prod de la V52




[APP-21944] [cob] Arrêt du cobranding ACF Création: 02/sept./08 09:58  Mise à jour: 21/janv./09 11:44  Résolue: 12/déc./08 10:07

Etat: Fermé
Projet: Application PriceMinister
Composants: Cobrandings
Affecte la/les version(s): 27.0.1
Version(s) corrigée(s): 39.0.0 (CTN-I)

Type: Amélioration Priorité: Majeur
Rapporteur: Ghislain Gridel Attribution: Dispatcher (Pôle CTN)
Résolution: Doublon  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Duplicate
doublon de APP-23166 Suppression cob ACF Fermé
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***
WishList: Marketing
WishList - Complexité: L
Classif FONC: cobranding

 Description   
Bonjour,

ACF souhaite arrêter notre partenariat. Il a pris fin offciellement le 31/08/08. Pouvons-nous activer la procédure de débranchage du cobranding ?

1 / Faire rediriger http://www.radindesbois.com/ vers PM (Exploit)
2 / Arrêter les rapports BI hebdo et mensuel (Décisionnel)
3 / Envoyer un email à tous les comptes pour leur dire qu'ils peuvent continuer à acheter sur PM (Marketing)

Ai-je oublié quelque chose ?
Ghislain

 Commentaires   
Commentaire de Alexandre Garnier [ 12/déc./08 10:07 ]
APP-23166




[BIN-476] [Sales/ES] : Rapport hebdo Volume d'affaire comptes dvdlegacy sur l'Espagne Création: 21/août/08 16:47  Mise à jour: 01/oct./08 10:34  Résolue: 22/août/08 10:08

Etat: Fermé
Projet: Business Intelligence
Composants: Sales
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Gaël Seguillon Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne

 Description   
J'aurai besoin d'avoir un rapport BI, si possible accessible depuis mon dossier sur ur sales mes favoris/Gael qui présenterait chaque semaine, le volume d'affaire des 3 comptes de dvd legacy sur le site espagnol
les logins concernés et les ID vendeurs sont les suivantes
legacybooks (10979245)
dvdlegacycd (10873093)
dvdlegacy_es (10873092)

les données dont j'aurai besoin sont un rapport hebdo détaillant pour une semaine l'ensemble des chiffres suivants pour les 3 pseudos de ce pro
volume d'affaire (Captured gross merchandise sold) - commission price fixe (captured fix commission) - commission price variable (captured variable commission)

merci
Gael


 Commentaires   
Commentaire de Cyril Tanneau [ 21/août/08 18:48 ]
Bonjour,

Nous avons vu ensemble la création du rapport.

En attente des résultats de la planification...

Merci,

Cyril
Commentaire de Cyril Tanneau [ 22/août/08 10:08 ]
Bonjour,

Tout a l'air de bien fonctionner, le rapport a été correctement généré et envoyé.

Gaël, peux-tu vérifier que le rapport est bien envoyé Lundi comme nous l'avons programmé, et clôturer le JIRA si tout est OK.

Merci,

Cyril
Commentaire de Agathe Remy [ 04/sept./08 14:35 ]
Bonjour Gaël,

Peux-tu valider la demande afin que nous la clôturions?

Merci.

Agathe




[BIN-657] [Cobranding] : Actualisation du rapport "PriceMinister - Authorized co-branding type LRO" avec l'information "Refused negociated GMS" Création: 25/févr./10 18:21  Mise à jour: 25/mars/10 17:20  Résolue: 25/mars/10 17:20

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Jonathan Gorges Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Comme vu ensemble, nous voulons actualiser le reporting BI "PriceMinister - Authorized co-branding type LRO" se situant dans le dossier public "Cobranding".

Sauf erreur de ma part, la colonne appelée "VA Buyer" doit aujour'hui inclure les négociations refusées.
Pourriez-vous dans un premier temps vérifier si cela est bien vrai svp ?

Aussi, nous voudrions inclure sur la droite de ce rapport, en dernière colonne (pour ne pas perturber nos tableaux croisés dynamiques") une colonne "Refused negociated GMS".

Je reste à votre disposition pour toute information complémentaire.

PS : Dalila, les rapports de COB présents à la fois dans le dossier privé d'Aurélie et dans le dossier public COB sont bien les mêmes.

Jonathan



 Commentaires   
Commentaire de Cyril Tanneau [ 25/mars/10 17:20 ]
Jonathan,

comme vu ensemble à l'instant, le rapport PriceMinister - Authorized co-branding type LRO permet de ressortir les VA acheteurs, VA vendeurs et VA Acheteurs/vendeurs cobrandés.

Ces montants sont capturés, ils ne comprennent donc pas de négo refusées, qui par définition ne sont pas capturées.

Je ferme donc le JIRA,

Merci,

Cyril




[BIN-430] [SBP] : Prise en compte des suppressions de colonnes Création: 15/avr./08 16:08  Mise à jour: 17/août/09 15:41  Résolue: 10/juin/08 10:08

Etat: Fermé
Projet: Business Intelligence
Composants: Bug & Improvement
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Prendre en compte les suppressions de colonnes suivantes en même temps que les impacts de la centralisation PMV (objectifs MEP mi-mai):

ALTER TABLE prd_configuration DROP COLUMN is_cpl_mono_advert;
ALTER TABLE image DROP COLUMN is_migrated;
ALTER TABLE prd_attribute DROP COLUMN is_inherited ;
ALTER TABLE compensation DROP COLUMN old_ubk_iban_control;
ALTER TABLE usr_bank_account DROP COLUMN old_iban_control;

Les éléments possiblement impactés sont :
- alimentation BI (ODS/DTM, France/Espagne)
- rapports titan
- flux partenaires (1000Mercis)

Merci.
Agathe




[BIN-572] Rapport vendeurs catégorie mode Création: 30/mars/09 18:36  Mise à jour: 30/avr./09 16:18  Résolue: 30/avr./09 16:18

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Charlotte Fachan Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut à tous,

nous souhaitons informer nos vendeurs de la mise en place du nouveau formulaire mode et accessoires.
Les objectifs du mailing sont :
o augmenter le nombre de mev Mode abouties
o augmenter la qualité des annonces enregistrées
o augmenter le nombre de vente dans la catégorie mode.

J'aurais aimé un comptage pour affiner les cibles de notre emailing.

Je souhaiterias connaître le nombre vendeurs qui ont fait une mev dans la catégorie mode (et accessoires de mode) avant le 13/11/08 et qui aujourd'hui n'ont toujours pas vendu leur article.
j'ai commencé un rapport que j'ai enregistré dans mon public mais je bug un peu.

Dans l'idéal j'aurais aimé aussi connaître le nombre de vendeurs qui ont fait une mev « non aboutie ». A t - on cette info dans BI ?

Merci

Charlotte



 Commentaires   
Commentaire de Agathe Remy [ 28/avr./09 16:07 ]
Bonjour Charlotte,

La News Vente annonçant la mise en place du nouveau formulaire mode et accessoires ayant été envoyée le 17/04, cette demande est-elle obsolète?

Merci.
Agathe
Commentaire de Charlotte Fachan [ 30/avr./09 16:10 ]
effectivement ;-)

merci. Charlotte




[EXP-4892] création d'alias pour le back office Création: 16/juil./09 11:04  Mise à jour: 16/juil./09 17:29  Résolue: 16/juil./09 17:29

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Steven Harel Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
afin de supprimer définitivement les adresse personnelles des destinataires des rapports bi, j'ai besoin de quelques nouveaux alias :

bo.sav.fr.1@priceminister.com
avec en destinataires :
jemima.pinel@priceminister.com
jeff.stanley@priceminister.com
manuela.paillussiere@priceminister.com
vanessa.bader@priceminister.com

bo.sav.fr.2@priceminister.com
avec en destinataires :
jonathan.lesage@priceminister.com
pierre-edouard.battistini@priceminister.com
celine.maraud@priceminister.com
stephanie.boillon@priceminister.com

bo.sav.fr.3@priceminister.com
avec en destinataires :
eve.pioche@priceminister.com
axelle.lirvat@priceminister.com
rachid.guernane@priceminister.com
graziella.seide@priceminister.com

bo.sav.retours@priceminister.com
avec en destinataires :
pierre.smith@priceminister.com
xavier.courla@priceminister.com

bo.sav.es.1@priceminister.com
avec en destinataires :
laura.yeo@priceminister.com
juanluis.fajardoruiz@priceminister.com

bo.sav.uk.1@priceminister.com
avec en destinataires :
laura.yeo@priceminister.com
oliver.moss@priceminister.com
thomas.springett@priceminister.com

bo.finance@priceminister.com
avec en destinataires :
claire.durand@priceminister.com
graziella.seide@priceminister.com
steven.harel@priceminister.com

bo.fraudes@priceminister.com
avec en destinataires :
sebastien.bruzzone@priceminister.com
julien.griffon@priceminister.com
steven.harel@priceminister.com

bo.validation@priceminister.com
avec en destinataires :
aurelien.vergalli@priceminister.com
xavier.fabregat@priceminister.com
sandra.ferrero@priceminister.com

bo.contrefacon@priceminister.com
avec en destinataires :
xavier.courla@priceminister.com
sandra.ferrero@priceminister.com
steven.harel@priceminister.com

bo.cosav@priceminister.com
avec en destinataires :
laura.yeo@priceminister.com
habib-sylvain.gourguet@priceminister.com
jonathan.lesage@priceminister.com
steven.harel@priceminister.com

 Commentaires   
Commentaire de Stéphane Eccli [ 16/juil./09 16:24 ]
les adresses sont créées sur le serveur.
est ce qu'elles seront utilisées depuis l'extérieur ou juste en interne ?
Commentaire de Steven Harel [ 16/juil./09 16:44 ]
juste en interne

merci !
Commentaire de Stéphane Eccli [ 16/juil./09 17:29 ]
done




[BIN-701] Création d'un univers "ITEM EVENT" Création: 29/déc./10 19:07  Mise à jour: 17/févr./11 14:51  Résolue: 16/févr./11 16:31

Etat: Résolu
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Habib-Sylvain Gourguet Attribution: Valéria Gusa
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
L'équipe TX a récemment effectué (dans le cadre du CoSAV) des développements majeurs à l'attention du Back Office :

- ajout de l'identifiant BO dans plusieurs "événements article" (notamment ceux liés au processus de réclamation),
- mise en place du gestionnaire de commandes, avec là aussi de nouveaux "événements article" (ex. : annulation de la vente par le vendeur).

Le Back Office souhaiterait s'appuyer sur BI pour mieux analyser le comportement de certains utilisateurs d'une part (pour de futurs développements, meilleure détection de la fraude...), et l'évolution de l'activité du pôle SAV d'autre part (actions effectuées sur les articles, nombre de traitements réalisés sur une réclamation...).

Un univers "ITEM EVENT" permettra une meilleure appréciation de ces données, là où des univers existants tels que "ITEM" ou "MESSAGE" (déjà utilisés dans certains rapports) montrent leurs limites.

 Commentaires   
Commentaire de Habib-Sylvain Gourguet [ 29/déc./10 19:08 ]
Steven en copie pour info.
Commentaire de Habib-Sylvain Gourguet [ 11/janv./11 10:50 ]
Emeric et Thomas en copie pour info.
Commentaire de Valéria Gusa [ 16/févr./11 16:31 ]
Bonjour Habib,

L'univers ITEM EVENT vient d'être livré sur les trois pays FR/ES/UK.


Merci
Valeria
Commentaire de Habib-Sylvain Gourguet [ 16/févr./11 19:22 ]
Génial, merci à toi et à Julien.

Quelle rapidité ! :-)

Je n'hésiterai pas à revenir vers vous pour d'éventuelles remarques.
Commentaire de Steven Harel [ 17/févr./11 14:45 ]
ouais ça avance bien, c'est cool, merci
On se voit pour voir tout ce qu'on peut faire avec ça
Commentaire de Valéria Gusa [ 17/févr./11 14:51 ]
Je refais juste un petit point pour donner un peu plus de précision sur les possibilités liées au nom de l'opérateur.

Nous avons mis a disposition deux objets :
_ La dimension "Iten event operator name" qui permet d'afficher le nom de l'opérateur BO qui a traité l'événement.
_ Le filtre " Select item event operator" qui permet de sélectionner tous les évènements traités par un opérateur en particulier. Ce filtre n'est pas sensible à la casse mais est sensible aux accents.

Merci
Valeria




[APP-17272] Abonnements Création: 25/juil./07 15:21  Mise à jour: 17/août/07 11:11  Résolue: 16/août/07 14:28

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 15.0.1, 15.0.2, 15.0.3, 15.1.0
Version(s) corrigée(s): 16.0.0

Type: Bogue Priorité: Critique
Rapporteur: Agathe Remy Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Bug_subscription_events_20070726.xls    
Pays:
ALL - Tous
Projets PM archivés: Maintenance 16.x.x

 Description   
Bonjour,

En mettant en place le reporting sur les abonnements, j'ai constaté certaines incohérences dans les données:
-Un évènement " Abonnement aux ventes évènementielles proposées par 24h" avec la description "Migration refonte abonnements (APP-15697)" est créé en double sur des comptes inscrits alors qu'ils ne sont pas optin 24h (case à cocher vide dans le BO).
-Un script post-deploy a tourné tous les jours depuis le 12/07/2007, créant des évènements avec une date de création antérieure à leur date réelle de création et donc créant des incohérences entre le BI et les données du site. Nous avons désactivé sa programmation avec Patrice.

Je suis à votre dispo si vous avez besoin de plus de précisions.

Agathe

 Commentaires   
Commentaire de Arnaud Forgues [ 26/juil./07 10:23 ]
Agathe, pourrais-tu me donner des exemples de comptes ? Merci
Commentaire de Agathe Remy [ 26/juil./07 11:30 ]
Tu trouveras ci-joint la liste exhaustive des évènements "24H" créés avec une date de création antérieure à leur date réelle de création et comprise entre le 13/07/2007 et aujourd'hui.
En revanche, sur la journée du 12/07/2007 je ne sais pas débrouiller le juste du faux...

Agathe
Commentaire de Arnaud Forgues [ 26/juil./07 18:19 ]
Merci !

Pour te rassurer, je te confirme qu'il n'y a que des abonnements de type 24h qui sont concernés par ce pb.
Commentaire de Arnaud Forgues [ 27/juil./07 10:30 ]
On a donc a priori 35470 évenement à supprimer.

Ils le seront en PROD grâce au script suivant :

V:\Database\V16_0_0\integ\01_PREPARE\ONLINE\V16_0_0_APP_17272_FRA_01_usr_event_delete_24h.sql

Patrick, je te transmet donc le JIRA pour que tu passes ce script en PRE DEPLOY de la V16 dès que possible

Merci
Commentaire de Agathe Remy [ 27/juil./07 18:43 ]
Un second problème est apparu : il semble qu'il y ait de très nombreux doublons sur l'évènement 140 et la journée du 12/12/2007.
Voici la requête que j'ai effectuée pour rechercher ces doublons :
SELECT user_account_id,
creation_date,
mail_subscription_id,
COUNT(DISTINCT usr_event_id)
FROM usr_event
WHERE use_type_code=600
AND description LIKE '%APP-15697%'
GROUP BY user_account_id,
creation_date,
mail_subscription_id
HAVING COUNT(DISTINCT usr_event_id)>1
;

Le résultat se trouve dans le fichier : V:\Reporting\BusinessIntelligence\Evolutions\Subscription\doulons_listing.csv (plus de 2 000 000 d'enregistrements).

J'ai vérifié, et il n'y a pas de doublon sur USR_SUBSCRIPTION.

Agathe



Commentaire de Patrick Pereira [ 31/juil./07 12:49 ]
En effet. Il y a un problème.
J'ai l'impression que le 12/7 on a lancé 2 fois en même temps le script d'insertion.
Je vais faire un script correctif.
Commentaire de Patrick Pereira [ 16/août/07 14:28 ]
C'est corrigé.




Contrat Bris&Vol [Metatache] (APP-16575)

[APP-16620] Notez vos vendeurs :: Fonctionnalité « Demander de l'aide » Création: 06/juin/07 10:02  Mise à jour: 08/oct./07 15:16  Résolue: 26/sept./07 15:34

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 14.2.0
Version(s) corrigée(s): 17.0.0

Type: Sub-bug Priorité: Mineur
Rapporteur: Richard Dubois Attribution: Swan Desportes
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File noter_le_vendeur.JPG    
Pays:
ALL - Tous
Site: Prod
Projets PM archivés: Contrat "Bris et Vol"

 Description   
Actuellement pour effectuer une réclamation, au niveau de la page « Notez vos vendeurs », une proportion non négligeable d'acheteurs utilise le lien « >> Noter votre vendeur » au lieu du lien « >> Demander de l'aide », sans se rendre compte qu'il s'agit de 2 liens distincts car ils sont très proches l'un de l'autre. Ainsi, l'acheteur pense que sa demande est prise en compte par le SAV et qu'elle sera traitée. Or, le SAV ne contrôle / surveille pas les messages de notation et ne peux donc pas répondre aux réclamations effectuées par ce biais, ce qui génère de l'insatisfaction.

La mise en place des garanties sur PriceMinister risque d'augmenter ce phénomène. Il semble donc pertinent de traiter ce problème en préliminaire du chantier garantie.

Sur la page « notez vos vendeur » sauter une ligne et mettre un espace significatif entre les liens « >> Noter votre vendeur » et « >> Demander de l'aide ».

 Commentaires   
Commentaire de Sébastien Aubert [ 17/juil./07 18:20 ]
Ce problème est traité dans le projet reserve "transaction notée/ produit non reçu" jira APP-15713
Commentaire de Alexandre Garnier [ 26/sept./07 15:34 ]
TNNR
Commentaire de Sébastien Aubert [ 08/oct./07 15:16 ]
ok traité avec projet TNNR




[APP-24551] [Liens sponsos Keyade] Nouveaux tags Keyade/Xiti Création: 09/mars/09 18:00  Mise à jour: 11/mars/09 16:27  Résolue: 11/mars/09 10:33

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 42.0.0 (CTN-J)
Version(s) corrigée(s): 42.0.1

Type: Tâche Priorité: Majeur
Rapporteur: Damien Dorizy Attribution: Damien Dorizy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Description   
Afin de pousser plus loin les tests pour comprendre pourquoi 20% des tags Keyade ne sont pas remontés, on souhaite mettre en place ce qui suit :
- Pour chaque tag Keyade posé, on pose un tag Xiti (dans la fonction JS pour avoir des conditions similaires)
- Les tags "tests" Keyade (dtool.keyade.com) sont posés avec la méthode javascript "document.write", à la différence des tags "normaux" (k.keyade.com) qui utilisent toujours la méthode new Image(), afin de pouvoir évaluer un éventuel problème à ce niveau là.
- Si le cookie "slid" n'est pas trouvé (ce qui ne devrait pas être le cas), on pose un tag Xiti.

Cela permettra de confondre les informations Xiti avec celles du BI et de Keyade, et peut-être de déterminer la cause du problème.

 Commentaires   
Commentaire de Damien Dorizy [ 09/mars/09 18:04 ]
cms1 + cms3
/promotions/Promotions/FR/Liens sponso/Keyade/Panier - 3 tags - test
/promotions/Promotions/FR/Liens sponso/Keyade/Panier - 3 tags
/promotions/Resource/pr.js

merci
Commentaire de Christophe Garcia [ 09/mars/09 18:43 ]
J'espère que vous avez testé ce truc à mort.
Cette évolution n'a fait l'objet d'AUCUNE DISCUSSION avec l'équipe d'INTEG : elle est livrée à 18H le jour du bouclage de la version.
Commentaire de Damien Dorizy [ 10/mars/09 09:56 ]
Ok pour 42.0.1




[APP-17315] probleme sur les montants capturés operation sur 4 paniers Création: 26/juil./07 17:42  Mise à jour: 08/août/07 18:59  Résolue: 06/août/07 17:44

Etat: Fermé
Projet: Application PriceMinister
Composants: Base de données, Panier
Affecte la/les version(s): 15.1.2
Version(s) corrigée(s): 15.1.2

Type: Bogue Priorité: Majeur
Rapporteur: Romain Czornomaz Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à APP-14077 Problème avec le porte monnaie Fermé
Pays:
FRA - France
Site: Prod
Projets PM archivés: Maintenance 15.x.x

 Description   
Bonjour,

il y a en production 4 paniers dont les montants operation de la table OPERATION sont bien passés en finalisé mais les montants capturés operation (CAPTURE_OPERATION_AMOUNT) dans la table PURCHASE n'ont pas été mis à jour.

Paniers impactés:
34145670 --> montant: 8.75
34156881 --> montant: 14.33
34157335 --> montant: 20.2
34500782 --> montant: 250.3

Pouvez vous regarder pour corriger le probleme?
NB: En cas d'UPDATE sur la table PURCHASE, pensez à mettre à jour la CHANGE_DATE afin que les modifications soient prise en compte dans l'alimentation BI.


 Commentaires   
Commentaire de Romain Czornomaz [ 27/juil./07 14:49 ]
Genevieve,

Voici le numéro de la demande que tu avais traité auparavant.

Bonne journée,

Romain
Commentaire de Geneviève Beaujard [ 31/juil./07 16:03 ]
Peux tu passer le script APP17315_FRA_update_purchase.sql qui se trouve dans V15_1_1
Commentaire de Patrick Pereira [ 06/août/07 17:44 ]
C'est fait.




[APP-20690] Impossible de refuser une opération de crédit BO depuis le détail operation Création: 29/mai/08 11:04  Mise à jour: 30/mai/08 14:56  Résolue: 30/mai/08 10:31

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 22.1.1
Version(s) corrigée(s): 22.1.2

Type: Bogue Priorité: Critique
Rapporteur: Arnaud Forgues Attribution: Arnaud Forgues
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Classif1: PMV
Classif2: operation
Projets PM archivés: Paiement - Automatisation bordereaux

 Description   
Depuis le déploiement de la TX-A, il est impossible d'éffectuer un refus sur un crédit BO, dans le cas où le SAV a utilisé la macro de remboursement PMV à tort. Du coup, ils sont obligé de finalisé les opérations puis de créer une opération de débit BO du montant opposé. Cela n'est pas du tout pratique et on n'a aucun lien entre ces 2 opérations si on souhaite les rapprocher ultérieurement dans des rapports BI.

Du coup, il faut autoriser le refus d'une opération dans l'état APPROVED dans le cas ou il s'agit d'un crédit BO.

A tester donc uniquement le refus d'une opération en BO : c'est le seul impact possible de la correction

 Commentaires   
Commentaire de Emeric Teil [ 29/mai/08 13:30 ]
Quid des Crédit Bo Récup chèque et des débits BO ???
Commentaire de Arnaud Forgues [ 30/mai/08 10:31 ]
oK




[APP-29031] Tirage au sort du gagnant jeu concours widget de mars Création: 06/avr./10 11:11  Mise à jour: 25/juin/10 11:11  Résolue: 18/juin/10 17:05

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 72.0.0 (VEN-C)

Type: Tâche Priorité: Majeur
Rapporteur: Audrey Angleys Attribution: Fabrice Feugas
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***
WishList: Marketing
Classif1: WIDGET
Classif FONC: widget

 Description   
Hello,

La news d'annonce de fin du jeu concours widgets est supposée partir ce samedi 10/04.
(version perdants via MM / version gagnant grâce au nouveau système d'attribution de coupon avec mail via le Back Office).

Il faudrait donc sortir le fichier des personnes ayant participé => Fabrice/Renaud/BI?
Puis tirer au sort un gagnant => serait-il possible de créer un système dans le BO comme pour le jeu avis? Sinon, pouvez-vous transmettre le fichier des inscrits à Eric pour le tirage au sort comme la dernière fois?

Fabrice, je t'attribue le JIRA, pourras-tu me tenir au courant des démarches à suivre/personnes à qui m'adresser si besoin?

Merci beaucoup!

Audrey

 Commentaires   
Commentaire de Fabrice Feugas [ 18/juin/10 17:01 ]
Oula, pas déjà réglé depuis le temps ?




[APP-28871] Liste participants jeu concours avis Création: 24/mars/10 15:27  Mise à jour: 01/oct./10 11:43  Résolue: 13/août/10 16:17

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 65.0.1
Version(s) corrigée(s): 78.0.0 (CTN-TU)

Type: Amélioration Priorité: Majeur
Rapporteur: Carole Visser Attribution: Renaud Dierickx
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à BIN-658 [Avis] : Extract Inscrit au jeu conco... Fermé
Pays:
FRA - France
Projets PM: *** CHASSE ***
Classif FONC: avis

 Description   
Bonjour,

Dans la cadre du jeu concours permanent avis, un gagnant est tiré au sort chaque mois. On lui attribue donc son coupon et il est contacté directement par le BO.

Un mail est également envoyé par 1000Mercis à l'ensemble des autres participants pour leur annoncer qu'ils n'ont pas gagné ce mois ci et les inviter à retenter leur chance le mois prochain.

Les données d'inscription au jeu concours et les points accumulés ne sont transmis à 1000Mercis. Il faut donc générer la cible chaque mois et leur envoyer.

Pour le moment, l'équipe BI s'occupe de la requête mais il faudrait à terme pourvoir obtenir la liste des participants au jeu concours avis du mois M-1 au moment du tirage au sort depuis le BO.

Merci d'avance,

Carole


 Commentaires   
Commentaire de Fabrice Feugas [ 25/mars/10 12:00 ]
La liste doit aller du début du mois M-1 jusqu'au moment de l'extract, en sachant que le tirage au sort et l'extract devront être fait quasiment en même temps.

Agathe, peux-tu nous communiquer la requête que vous utilisez ?

Merci.
Commentaire de Agathe Remy [ 25/mars/10 12:11 ]
Voici le JIRA dans lequel vous trouverez la requête d'extraction.
Celle-ci se base sur vos critères de tirage au sort vu avec Renaud.

Agathe
Commentaire de Renaud Dierickx [ 13/août/10 16:17 ]
Sur la branche CTN.
Chasse comptant pour 2 :
http://perrier:8090/dev/pole/ctn/revision/25077
[CAJ2010Q3CTN]




[IMP-8128] WEBSERVICES : MOBILINNOV : explications Création: 22/févr./11 11:54  Mise à jour: 22/févr./11 11:54

Etat: Ouvert
Projet: Paramétrage - Import
Composants: Support entrant
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Laurent Payot Attribution: Laurent Payot
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: MOBILINNOV
Séparateur: N/A
Type de traitement:
N/A

 Description   
De : Yohan Azoulay [mailto:yazoulay@ihtconsulting.com]
Envoyé : vendredi 18 février 2011 10:21
À : 'Support Pro'
Objet : RE: Soumission Catalogue Priceminister par API

Bonjour,

Merci pour votre insertion rapide.

J'ai néanmoins une question. Est il possible de transférer les commandes PRICEMINISTER directement dans notre BACK OFFICE par le biais d'une API par exemple afin d'avoir une réactivité plus importante quant à la gestion des commandes.

Nous souhaiterions pouvoir visualiser la commande / Valider la commande / envoyer le numéro de suivi au client directement depuis notre Back Office.

Merci pour votre retour.

Cordialement,
Yohan Azoulay - Directeur informatique
www.portable-accessoire.com
01.77.35.78.34





[BIN-532] Tronquage de données rapport ur sales à j-3 Création: 19/déc./08 17:42  Mise à jour: 24/déc./08 14:11  Résolue: 24/déc./08 14:11

Etat: Fermé
Projet: Business Intelligence
Composants: Sales
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Dorian Porta Delsol Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
UR Sales --> Favoris --> Dorian --> Suivi vendeur (courte période)

Il y a donc un problème sur les chiffres des dernières journées qui semblent être tronqués (à partir de J-3) :

exemple sur le compte Espace3games du 20/10/2008 au 18/12/2008 :

nb de vente par jour (valeur back office) :

05/12/2008 8
06/12/2008 6
07/12/2008 11
08/12/2008 7
09/12/2008 14
10/12/2008 18
11/12/2008 15
12/12/2008 13
13/12/2008 27
14/12/2008 16
15/12/2008 15
16/12/2008 10
17/12/2008 20
18/12/2008 36

nb de vente par jour (rapport BI) :

05/12/2008 8
06/12/2008 6
07/12/2008 11
08/12/2008 7
09/12/2008 14
10/12/2008 18
11/12/2008 15
12/12/2008 13
13/12/2008 27
14/12/2008 16
15/12/2008 15
16/12/2008 10
17/12/2008 17
18/12/2008 10


Les valeurs sont inexactes pour le 17 et le 18 et aucun soucis sur les autres journées. J'ai exécuté le rapport le 19/12.

A votre disposition si besoin est.

Merci
Dorian


 Commentaires   
Commentaire de Dalila Belkebir [ 24/déc./08 14:11 ]
Vu entre Cyril & Dorian :

Le rapport se basait sur des statuts "finaux" de paniers .
Or ces statuts n'apparaissent pas pour les paniers les + récents.

Dalila.




[BIN-218] evaluation du test coupon vendeur Création: 10/nov./06 12:09  Mise à jour: 14/sept./07 17:31  Résolue: 19/janv./07 18:24

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello Agathe,

Nous allons bientôt faire un test sur le coupon vendeur.
Principe du test : Proposer aux acheteurs qui n'ont pas d'inventaire de découvrir la vente sur PM et leur attribuer un bon d'achat s'ils réalisent une 1ère vente clôturée sur le site.

Pour évaluer l'efficacité de cette opération, nous aurons besoin de connaître, pour chacun des mails comportant les coupons de 3,5 7 euros :
- le nb de coupons vendeur utilisé
- le nb d'acheteurs devenus vendeurs (date de dépôt de 1ère annonce is not empty)
- le nb d'acheteurs devenus vendeurs réels (au moins 1 vente cloturée)
- le CA généré
- le nb de paniers
...

Je voudrais voir avec toi comment nous allons receuillir le résultat de cette opération. Est-ce qu'un simple tracking et la mise en place d'un rapport sur BI suffisent ?
On s'en repale de vive voie si besoin.

alexandra




[BIN-452] [Sales] : Rapport de pricing pour les vendeurs pros Création: 28/mai/08 19:43  Mise à jour: 08/juil./08 10:53  Résolue: 03/juin/08 17:07

Etat: Fermé
Projet: Business Intelligence
Composants: Sales
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Florian Ambrosi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Contexte : début de mise en place de services de reporting pour les vendeurs professionnels afin de définir à terme des offres de souscription à ces services qui pourraient etre payantes.

Objectif : fournir aux commerciaux un rapport permettant d'identifier & d'exporter les annonces d'un vendeur professionnel dont le prix de vente est sensiblement supérieur au meilleur prix neuf des annonces de la même fiche produit. On parle bien du meilleur prix neuf, ce qui implique une limitation du scope de comparaison aux vendeurs PRO.

L'idée est de reprendre le rapport d'export de stock et de le faire évoluer afin de ne restituer que les annonces dont le prix de vente est supérieur de x% au meilleur prix neuf du même produit. Le seuil d'écart x serait à saisir dans une invite lors du rafraîchissement du rapport. D'autre part, les annonces du rapport seraient triées par écart décroissant.

Avant de faire évoluer le rapport, il s'agit de vérifier que l'information "meilleur prix neuf" est correctement alimentée dans BI et que cette information est fiable.


 Commentaires   
Commentaire de Justin Ziegler [ 30/mai/08 12:41 ]
J'ai modifié un peu la description.
Commentaire de Justin Ziegler [ 30/mai/08 14:24 ]
nb pour Gael et Benjamin : je pense qu'il sera interessant d'utiliser ceci avec en utilisant la fonction d'abonement par mail à un rapport hebdo par ex.
Commentaire de Agathe Remy [ 09/juin/08 17:22 ]
Bonjour,

Il est possible qu'un vendeur Pro vendent des produits d'occasion. Dans ce cas, il y a des chances qu'il n'existe pas de meilleur prix neuf sur la fiche produit.
Ainsi, peut-on restreindre le périmètre du rapport aux annonces neuves du vendeur pro?

Merci de votre retour.

Agathe
Commentaire de Justin Ziegler [ 09/juin/08 19:29 ]
on en parle de vive voix ?
Commentaire de Agathe Remy [ 10/juin/08 10:18 ]
Je propose donc de filtrer les annonces neuves et visibles sur les site (i.e. qui sont actives, ont du stock et ne sont pas périmées). Dans ce cas là, il existe toujours un meilleur prix neuf sur la fiche produit.

D'autres rapports pourront être envisagés ultérieurement pour exporter les produits d'occasion d'un vendeur pro dont le prix est supérieur au meilleur prix d'occasion. Mais l'information est alors moins pertinente puisqu'un produit d'occasion peut être "Comme neuf", en "Très bon état", en "Bon état", en "Etat correct" ou "Hors service" et nous ne disposons pas de l'information "meilleur prix" à ce niveau de détail aujourd'hui.

Autre rapport qui pourrait également envisagé : export des annonces sans stock ou périmées.

Agathe
Commentaire de Justin Ziegler [ 10/juin/08 10:44 ]
petite précision :
il me semble que les annonces HS ne sont pas prises en compte dans le calcul du "meilleur prix d'occasion"
Commentaire de Florian Ambrosi [ 10/juin/08 11:36 ]
Le rapport "New product pricing by login" est passé en prod en France et en Espagne dans le dossier "Sales".

Florian
Commentaire de Benjamin Guerville [ 10/juin/08 18:10 ]
ça à l'air top,
Agathe, par rapport à la formation dont tu m'as parlé, je vois ça avec PKR et les autres CDM mercredi et reviens vers toi




[APP-19587] Affecter les comptes pros à un commercial Création: 13/févr./08 18:06  Mise à jour: 07/déc./09 12:48  Résolue: 07/déc./09 12:48

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 19.0.0
Version(s) corrigée(s): 22.0.0

Type: Nouvelle fonctionnalité Priorité: Mineur
Rapporteur: Pierre Krings Attribution: Validator
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Site: Prod
Projets PM: *** RESERVE ***
Projets PM archivés: Espace "Commercial"

 Description   
A destination d'Emeric.
Projet Light vu avec QdC, a priori bon pour un traitement rapide en mode réserve.

Afin de faciliter la vie de l'équipe Commerciale, et d'être moins dépendant de l'outil 4D, l'idée est de renseigner directement dans la base de données le nom du commercial dont dépend chaque compte pro. Charge à l'équipe BI d'incorporer cette info dans les data marts qui conviennent. Benjamin en fera ensuite son affaire.

Qques pistes de ce qu'on souhaite :
- A priori, utile pour les pros mais c'est peut-être + simple de le prévoir pour tous les types de comptes quitte à ce que ça reste vide
- Nouveau champ "Commercial" dans la fenêtre "Droits"
- A priori champ libre, charge à benjamin de faire les modifs en cas de doublons dus à des erreurs d'orthographe (Dorian / DOrian)
- Remplissage One-shot de l'existant à partir d'un export de 4D
- La suite sera gérée manuellement par les cdm






 Commentaires   
Commentaire de Arnaud Forgues [ 06/mars/08 15:31 ]
un doc de conception est disponible à cette adresse : V:\Projets\reserve_fonc_JIRAs\Affecter_commercial_aux_comptes_pros
Commentaire de Emeric Teil [ 13/mars/08 14:29 ]
Comme prévu, cette demande est pour Habibata.
Commentaire de Emeric Teil [ 14/mars/08 09:26 ]
Pour info, voici ce qui sera implémenté :
-> Ancrage : fenêtre des "droits" sur la page User en BO
-> Fonctionnalité : une dropdown créée à partir de la liste des Commerciaux insérée dans le BackOffice (il sera donc possible d'ajouter, de supprimer ou de modifier des utilisateurs de type "commerciaux")

Voilà :o)

Commentaire de Emeric Teil [ 14/mars/08 09:27 ]
Dernière précision : cette information ne sera disponible que pour les vendeurs Pros
Commentaire de Pierre Krings [ 14/mars/08 10:14 ]
QQUES QUESTIONS/REMARQUES :

-> Fonctionnalité : une dropdown créée à partir de la liste des Commerciaux insérée dans le BackOffice (il sera donc possible d'ajouter, de supprimer ou de modifier des utilisateurs de type "commerciaux") : CA VEUT DIRE QU'IL FAUDRA CREER UN BACK OFFICE DE GESTION DES UTILISATEUR COMMERCIAUX ? J'AI L'IMPRESSION QUE C'EST PAS MAL DE BOULOT ET QUE CA RISQUE DE MANQUER DE SOUPLESSE DANS CERTAINS CAS, TOUT CA POUR EVITER QQUES DOUBLONS QUI NE SONT PAS UN GROS PB.

Dernière précision : cette information ne sera disponible que pour les vendeurs Pros
EST-ON SUR QU'IL N'Y AURA PAS DANS LE FUTUR D'AUTRES UTILISATIONS (SUIVI DE CLIENTS "VIP", FRAUDEURS OU TEMOINS, ETC),
QUID DES COMPTES QUI PASSENT DE PART A PRO PUIS PART A NOUVEAU ?
JE ME DEMANDE SI CE N'EST PAS PLUS SIMPLE DE LAISSER OUVERT ET DE SURVEILLER DE TEMPS EN TEMPS VIA BUSINESS OBJECT.

Commentaire de Habibata Coulibaly [ 21/mars/08 11:35 ]
Le projet est livré sur la branche TX_20082702
Commentaire de Emeric Teil [ 15/mai/08 19:35 ]
OK en Integ




[APP-28652] creation_date d'evenement operation (opr_event) antérieur à la creation_date de l'opération Création: 09/mars/10 14:54  Mise à jour: 09/mars/10 14:54

Etat: Ouvert
Projet: Application PriceMinister
Composants: Base de données
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Julien Girardet Attribution: Dispatcher (Pôle TX)
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
GBR - Royaume Uni
Site: Prod
Projets PM: *** A PLANIFIER ***

 Description   
Sur UK, on observe certaines operations créées en BDD après ses événements (OPR_EVENT.CREATION_DATE < OPERATION.CREATION_DATE)

exemple :
OPERATION_ID CREATION_DATE OPR_EVENT_ID CREATION_DATE
10241998 15/01/2010 00:00:42 4981174 14/01/2010 23:58:40
10241998 15/01/2010 00:00:42 4981175 14/01/2010 23:58:40
10473996 27/02/2010 00:00:43 4992134 26/02/2010 23:59:21
10473996 27/02/2010 00:00:43 4992135 26/02/2010 23:59:21

Impacts BI : Nous dénormalisons quotidiennement la date de "completion" d'une operation. Or lorsque ce phénomène se produit à cheval sur 2 jours (les événements créées la veille et l'opération créée le lendemain), notre calcul de dénormalisation est éronée.
Au final nous constatons des écarts sur les rapports de réconciliation des compensations.


Merci.




[APP-18598] Correction des montants capturés sur 2 paniers sur la base Espagne Création: 20/nov./07 18:21  Mise à jour: 27/nov./07 14:40  Résolue: 27/nov./07 14:26

Etat: Fermé
Projet: Application PriceMinister
Composants: Base de données
Affecte la/les version(s): 19.0.0
Version(s) corrigée(s): 17.2.1

Type: Tâche Priorité: Majeur
Rapporteur: Romain Czornomaz Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne
Site: Prod
Projets PM archivés: Maintenance 17.x.x

 Description   
Bonjour,

En analysant les écarts de la dette vendeur sur la plateforme Espagne, nous nous sommes rendus compte que 2 paniers effectués en Novembre 2006 par fred et Nerya avaient été passé en capture manuelle avec des montants cartes capturés à 0.
Or, il y a bien eu des commissions prélevées au niveau Item et les compensations sur les items ont été effectuées.
Afin de ne plus avoir d'ecarts sur la dette vendeur, il faudrait mettre à jour le montant carte capturé (capture_card_amount) de la table PURCHASE sur les paniers suiavnts:

- PURCHASE_ID= 34285834 , AUTHORIZATION_CARD_AMOUNT= 8 ------> UPDATE DE CAPTURE_CARD_AMOUNT = 8

- PURCHASE_ID= 34285835 , AUTHORIZATION_CARD_AMOUNT= 8 ------> UPDATE DE CAPTURE_CARD_AMOUNT = 8

Arnaud, peux-tu penser à mettre à jour la CHANGE_DATE pour les 2 enregistrements afin que nous puissions prendre en compte les modifs sur le BI.

Merci d'avance,

Romain

 Commentaires   
Commentaire de Arnaud Forgues [ 26/nov./07 19:05 ]
Bon c'est OK !

J'ai fait le script qui va bien et je l'ai passé en INTEG espagne et ca a l'air bon

le script est : V:\Database\V19_0_0\integ\V19_0_0_APP-18598_ESP_update_purchase.sql
Commentaire de Christophe Garcia [ 27/nov./07 14:19 ]
A toi de jouer
Commentaire de Patrick Pereira [ 27/nov./07 14:25 ]
C'est passé en prod.
Du coup j'ai renommé et déplacé le script : V18_0_0_APP-18598_ESP_update_purchase.sql




[APP-20695] [CoSAV] Messagerie BO - faire en sorte que les messages supprimés restent en répondu dans leur boite d'origine. Création: 29/mai/08 14:52  Mise à jour: 25/nov./09 17:42  Résolue: 04/nov./09 14:58

Etat: Fermé
Projet: Application PriceMinister
Composants: Back-Office
Affecte la/les version(s): 22.1.1
Version(s) corrigée(s): 58.0.0 (TX-K)

Type: Amélioration Priorité: Majeur
Rapporteur: Cedric Favero Attribution: Dispatcher (Pôle TX)
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***
Classif FONC: CoSAV

 Description   
Récemment , le BI nous a donné la possibilité de sortir des rapports sur les messages entrants/sortants.
Pour nous c'est un outil très important nous permettant de suivre par exemple le nombre de messages reçus dans telle ou telle boite.

Pour savoir la boite de réception du message ,on utilise le "incoming context" mais celui-ci ne garde pas obligatoirement sa valeur d'origine.
Si on transfère le message dans une autre boite , ce sera la derniere qui sera prise en compte.

Pb: pour les traitements SAV , bien souvent , on ne répond pas à proprement parler au message mais on le supprime et on clique sur une macro pour effectuer la traitement et envoyer un mail. Dans ce cas le message passe en état REPONDU et est transféré dans la boite TRASH.

Conséquence: les chiffres de nos rapports sont completement erronés car une proportion importante des messages apparait alors dans la boite TRASH.

=> question: est-il obligatoire qu'un message supprimé soit "transféré" dans la boite TRASH ? Ne pourrait-il simplement passer en l'état REPONDU et rester dans sa boite d'origine? Quelle difference celà ferait-il?




[IMP-6928] FOIRDISCOUNT : paramétrer format electroménager Création: 08/sept./10 15:30  Mise à jour: 08/sept./10 15:45  Résolue: 08/sept./10 15:45

Etat: Résolu
Projet: Paramétrage - Import
Composants: Support entrant
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Jérome Marianne Attribution: Jérome Marianne
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: FOIRDISCOUNT
Séparateur: N/A
Type de traitement:
Mise à jour/création annonces avec création produits (écrasement)

 Description   
Bonjour,
 
Ayant 1 article à créer, je souhaiterai le faire en mode "automatique" par transfert FTP (/stock/entree) ;
Voici les infos dont je dispose (à titre d'exemple) :
 
prix : 299.99
Etat : n (neuf)
quantité : 1
Référence interne : bal47256213
code article : 47256213 (ce n° figure sur le lien relatif à cet article)
Description : ** MEGA PACK ** BALAIS ASPIRATEUR À 4 BROSSES SANS FIL + CHARGEUR + NETTOYEUR + NOTICE FR (inovatec). _SATISFAIT, ÉCHANGÉ ou REMBOURSÉ/ENVOI SCELLÉ sous 24H/PRO FR/SAV/EN STOCK.
 
Je suppose que cet article est dans la catégorie "électroménager" ?
 
Mes tentatives de création par le biai du répertoire "entree" du FTP (/stock/entree) ont échoué;
 
Pouvez-vous me renvoyer un fichier XLS ( ou CSV) avec mes infos qui fonctionnerait ?
 
N.B.: Vous avez en pièce jointe mon fichier CSV qui n'a pas fonctionné..............
 
Merci,
 
Cordialement,
 
Philippe
FOIRDISCOUNT


 Commentaires   
Commentaire de Jérome Marianne [ 08/sept./10 15:45 ]
Format paramétré et rajouté dans Config FTP




[APP-24813] Possibilté d'extraire la base de données (produits + annonces) d'un pro FR pour récupérer les données réexportables sur une autre plateforme price Création: 27/mars/09 08:43  Mise à jour: 30/déc./09 10:02

Etat: Bloqué
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 43.0.2
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Gaël Seguillon Attribution: Dispatcher (Pôle VEN)
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: *** STANDBY ***
Classif FONC: commercial

 Description   

Cette extraction nous permettrait de pouvoir importer plus facilement nos catalogues français à l'international, après traduction et adaptation au format type spécifique à chaque pays. Aujourd'hui nous pourrions facilement mutualiser l'offre de certains pros sur les différentes plateformes avec cette solution notamment pour ceux qui ont créé tout leur inventaire manuellement : ex : superpromos et newstyls veulent vendre UK et ES mais n'ont pas de fichiers de stock

Le constat - simple : personne sur le plateau technique n'a les outils (programmes) pour faire ce type d'extraction aujourd'hui.
Comment avancer :

- Gaël, tu dois déterminer si ce cas va se représenter fréquemment - transfert de produits + stock de pays à pays.

- Si oui, il faut faire un JIRA APP en bonne et due forme (avec comme observateurs les responsables Dev, BI, Exploit et Param), et la demande sera orientée vers l'équipe la plus apte à s'outiller et fournir les données.


 Commentaires   
Commentaire de Benoît Bourdon [ 30/mars/09 18:43 ]
? en fait je ne comprends pas trop la demande ... je n'ai pas non plus l'impression que ce soit bien défini ...

Gaël, tu reviens vers moi quand tu veux - on regardera en détail le besoin, histoire de mieux comprendre.




Commentaire de Gaël Seguillon [ 30/mars/09 20:25 ]
En fait il s'agit de pouvoir à partir d'un inventaire d'un pro récupérer ses données annonces + produits, c'est à dire tous les éléments liés à son annonce (état, code, prix commentaire ...) mais également assez de données produits pour pouvoir lui réexporter le fichier avec les valeurs d'attributs suffisantes pour permettre de traduire un fichier qui est reexportable sur une autre plateforme Price et permet création produits +annonces
c'est assez intéressant pour les ouvertures de catégories UK et ES, on peut se voir rapidement pour se donner un idée de la faisabilité et du coût technique que ça représente ?
merci
Gaël




[APP-31399] Fiches produits avec un type de produit complément depuis septembre 2010 Création: 12/oct./10 17:17  Mise à jour: 26/nov./10 09:58  Résolue: 23/nov./10 14:28

Etat: Fermé
Projet: Application PriceMinister
Composants: Produits
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 81.1.2 (Clickintext + Redirections NPF FR et ES)

Type: Bogue Priorité: Critique
Rapporteur: Agathe Remy Attribution: Julien Sananikone
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Bug DECORATION_C - 2010-10-26.xlsx     Microsoft Excel Bug DECORATION_C.xlsx    
Liens des demandes:
Similaire
similaire à CAT-3284 Pseudo bobin02 : Impossible de modifi... Résolu
Pays:
FRA - France
Site: Prod
Projets PM: *** A PLANIFIER ***

 Description   
Bonjour,

Suite à une demande d'explication d'un écart entre 2 rapports BI demandée par Hisao-san, nous avons comparé le nombre d'articles global et la somme des nombre d'articles par famille de produit et nous nous sommes aperçu que certains articles n'étaient rattachés à aucune famille de produit parce qu'ils possèdent un type de produit complément : DECORATION_C.

Vous trouverez la liste de ces articles en pièce jointe avec les product_id associés : les fiches produits sont elles aussi associées au type de produit complément DECORATION_C.
Les premiers articles concernés ont été créés le 13/09/2010 et concerne 88 articles capturés sur septembre, soit un VA d'environ 1 200€.

Un rapide comptage nous indique qu'environ 7 000 fiches produits avec un base_product_id non renseigné sont ainsi rattachées au type de produit complément DECORATION_C.

Svp, pouvez-vous regarder ce qu'il en est et corriger les données ?

Nous sommes à votre disposition si vous avez besoin de plus d'info.

Merci,
Agathe

 Commentaires   
Commentaire de Agathe Remy [ 12/oct./10 17:19 ]
Liste des articles avec type de produit DECORATION_C
Commentaire de Jérôme Viviès [ 13/oct./10 17:36 ]
Ok, le JIRA est arrivé au bon endroit.

Cela semble lié à une migration de produits que nous avons faite récemment, du type "Jouet" vers le type "Décoration".

Le paramétreur en charge du dossier est absent actuellement et sera de retour lundi - il regardera ce problème en priorité.

S'il s'agit d'une urgence absolue, merci de le signaler ici + passer me voir.
Commentaire de Martin Sudmann [ 14/oct./10 10:49 ]
si ça existe réellement, des cpl sans base_product_id, on a un grave trou dans l'appli...

Ca relève de MEV ou import de fichiers.
Commentaire de Agathe Remy [ 14/oct./10 11:05 ]
Je pense que ça peux attendre le début de la semaine prochaine, mais pas beaucoup plus.
A noter qu'après avoir corrigé la configuration des fiches produit et annonces, il faudra également prévoir un script de correction du prd_type_code dans ITEM avec mise à jour de la change_date.
A voir aussi s'il n'y a pas des évènements à créer pour maintenir la cohérence des données et s'il n'existe pas d'autres dénormalisations du prd_type_code à corriger...

Agathe
Commentaire de Benoît Bourdon [ 15/oct./10 14:20 ]
Hello

Après avoir démêlé tout ça ...

Concernant la modélisation :
Il y a effectivement eu une migration produit Jouet (modélisation simple : produit - annonce) vers décoration (modélisation complément : Produit - Complément - Annonce)
La migration se déroule par import et ne fait que modifier le Prd_type_code des produits
---> mais ça ne créer évidement pas de produit base // complément en recréant toutes les liaisons qui vont bien ...etc...
La migration d'un type simple vers un type complément est impossible (la réciproque aussi)

Dans le coup tous ces produtis (environ 7000) se retrouve physiquement en modèle simple (produit - annonce) mais portent le type produit decoration_C !!!
Et donc les item générés à partir de ces produits portent donc (je suppose) physiquement le type decoration_C ...

Concernant le données / le reporting :
Dans le coup les items sont en decoration_C --> ils ne rentrent dans aucune famille en terme de reporting et ce sur pas mal de rapports (chez Rakut, chez Philippe, chez les commerciaux ...).
Correction alternative : affecter les produit complément à une famille dans la conf produit ... à encore ça impacterais un certain noùbre de rapport dans les diverses équipes.
Donc pas d'autre solution que de reprendre les données.


Solution :
1- Coté modélisation produit : Revenir en arrière : ramener tous les produits dans le type jouet (et identifier si il y a eu d'autre cas similaire - c'est probable, il faut reprendre la demande initiale de Many) : Julien / Fabien ont tous les éléments pour le faire normalement.
2- Coté reporting : prendre en compte ce bug temporairement ...
3- Coté données générée dans les items : Reprendre les données pour les X items considérés : pilotage à faire entre Param et Exploit (mais ça vaut le coup que la requête de migration / réparation soit relue par Manu et Arnaud qui maitrise les domaine modèle produit et item ...)

Je vous laisse créer les jiras / demandes ...etc...

-------------------------------------

A priori il faudrait faire le point 1 rapidement (lundi ?) pour éviter de générer toujours plus de données erronées dans les items.
Commentaire de Julien Sananikone [ 21/oct./10 15:05 ]
j'ai réimporté les produits dans jouets:
http://bo.priceminister.com/datafile_back?action=advfilesearch&file_id=&login=cat-pm1&process_code=&status=&use_proc_date=false&start_date=20%2F10%2F2010&end_date=&order=&x=0&y=0

les erreurs sont dues à des produits qui ont été supprimés entre temps.
Commentaire de Agathe Remy [ 26/oct./10 14:56 ]
Voici la liste des produits créés hier avec le type DECORATION_C
Commentaire de Julien Sananikone [ 26/oct./10 15:17 ]
il reste des mappings dans l'arbre import (exemple : http://bo.priceminister.com/category_back?action=categoryview&categorykey=122286)
--> il faudrait une requête pour les récupérer et les updater
Commentaire de Julien Sananikone [ 26/oct./10 16:18 ]
les 2 types codes compléments en erreur sont
2060 : decoration_c
1860 : cosmetique_c
Commentaire de Julien Sananikone [ 26/oct./10 17:29 ]
j'ai retiré les références à ces types compléments dans les mappings suivant

SQL> select ctg_parameter.category_id from ctg_parameter, category
where
category.category_id = ctg_parameter.category_id
and ctg_parameter.ctp_type_code = 1000
and ctg_parameter.NUMBER_VALUE IN (1860, 2060)
and category.ctg_type_code = 60
; 2 3 4 5 6 7
 
CATEGORY_ID
-----------
     197990
     198004
     121740
     121750
     323689
     122289
     348533
     349835
     260551
     260560
     121614
     121741
     122285
     122286
     349852
     122284
     121720
     348529
     348530
     197991
     328548
     121620
     122306
     121719
     121743
     122283
Commentaire de Julien Sananikone [ 23/nov./10 14:28 ]
Toutes les actions de réprataions ont été menées : Param et DBA




[APP-28479] Problème à nouveau sur 2 cas d'arrondis au centime inférieur sur les livres Decitre se plaint Création: 25/févr./10 13:32  Mise à jour: 10/déc./10 12:05  Résolue: 07/déc./10 14:24

Etat: Fermé
Projet: Application PriceMinister
Composants: Annonces
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 83.0.0 (VEN-F)

Type: Tâche Priorité: Mineur
Rapporteur: Anne Korchia Attribution: Benoît Bourdon
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Zip Archive BIBLIOGRAPHIE_2010_01_16.zip     Zip Archive BIBLIOGRAPHIE_2010_01_21.zip    
Pays:
FRA - France
Projets PM: *** RESERVE ***
Classif1: MEV
Classif2: lang
Classif FONC: commercial

 Description   
Voilà le mail de la responsable chez Decitre (decilibris et toutilibris chez PM)

Nous venons de constater à nouveau deux cas d'arrondis au centime inférieur qui font apparaître un marchand avant nous, dans la liste de résultats, alors qu'il est moins bien noté que nous (4.4 alors que 4.6 pour notre boutique toutilibris).

Il s'agit de la boutique « DMNEUF », ci-joint les captures d'écran, pour les articles 9782870971154 à 13.77 au lieu de 13.78 ¿ et de la boutique « TDMNEUF » et « lechocdumois » pour 9782350132082 à 18.90 au lieu de 18.91¿.

Merci de faire le nécessaire très rapidement car nous sommes pénalisés par cette « tricherie » et de vérifier si d'autres produits de ces marchand sont également avec un prix neuf faux et également si d'autres marchands utilisent aussi cette technique pour biaiser les résultats.

 Commentaires   
Commentaire de Gaël Seguillon [ 25/févr./10 14:00 ]
Salut
Grosse colère chez Decitre, des vendeurs recommencent à jouer sur l'arrondi, j'ai vu les comptes concernés sur certains ça peut se comprendre car loi Lang débloquée, à ce niveau à nous de faire la police mais d'autres cas plus problématiques de comptes avec option Loi Lang bloquée et offre jouant sur l'arrondi datant de 2010.
http://bo.priceminister.com/advert_back?action=advertbackview&advertid=261047601
Commentaire de Benoît Bourdon [ 25/févr./10 15:08 ]
Hello, je viens de creuser le jira :

J'ai regardé l'annonce d'un pro en question "lechocdumois" : sur l'écran BO, on voit que son annonce n'a pas été faite / modifiée par fichier d'import et donc elle vient du front office et date du 21/01/2010.
--> donc j'ai essayer de reproduire le problème en integ.

Ensuite j'ai aussi essayé de jouer avec les arrondis ... rien à faire on ne peut pas passer outre la loi lang ...

et donc si je regarde la fiche produit sur l'Integ. http://bo.pm.lan/referential_back?action=productview&productid=92665196
(qui est une image de la prod ayant quelques semaines d'ancienneté)
La fiche produit concernée à un prix d'origine à 18.90 --> le Pro à tout à fait le droit de mettre son annonce à 18.90 ... et la Mev fonctionne bien.

Ensuite je suis aller voir la fiche produit en prod : http://bo.priceminister.com/referential_back?action=productview&productid=92665196
là le prix d'origine est différent et est à 19.90

--> J'ai l'impression que le prix d'origine a changé suite à un import fait après le 21 janvier 2010 ...
--> Est ce qu'on peut fouiller coté import sur les derniers fichiers qui ont touchés ce produit svp ?
Commentaire de Gaël Seguillon [ 25/févr./10 15:36 ]
cool ça voudrait dire que ça fonctionne bien mais que c'est du à une modification du prix de référence.
Jerôme on peut voir côté Catalogue ?
merci
Gaël
Commentaire de Marion Anfreville [ 25/févr./10 17:00 ]
Bien pensé.

Un chance qu'on copie encore les fichiers de mise à jour decitre en sauvegarde (jusqu'à une certaine date...) sinon je n'aurais pu vous donner cette info.

Ce qu'on constate dans les mises à jour decitre :

BIBLIOGRAPHIE_2010_01_16.zip:9782350132082 9782350132082 Histoires secrètes d'une imposture Jean-Claude GawsewitchµParisµFrance 235013 Coup de gueule SODIS 3012600500000 GodardµBrunoµ1µ1µµµµµ 22.00 x 14.00 x 2.00 cm 0.3250 253 16/01/2010 14/01/2010 01/01/2010 21/01/2010 Photo : copyright A. Bertram. Sports Sport Football 18.90 17.91 5.50 Broché Disponible 16/01/2010

BIBLIOGRAPHIE_2010_01_21.zip:9782350132082 9782350132082 Histoires secrètes d'une imposture Jean-Claude GawsewitchµParisµFrance 235013 Coup de gueule SODIS 3012600500000 GodardµBrunoµ1µ1µµµµµ 22.00 x 14.00 x 2.00 cm 0.3250 253 16/01/2010 14/01/2010 01/01/2010 21/01/2010 Photo : copyright A. Bertram. Sports Sport Football 19.90 18.86 5.50 Broché Disponible 16/01/2010


En gros, dans le fichier du 16/01/2010, le prix d'origine est encore de 18.90 euros.

A partir du fichier du 21/01/2010, le prix d'origine est à 19.90 euros.

Les fichiers soumis sont en pj du jira.
Commentaire de Espérance Galouo-Lece [ 26/févr./10 10:56 ]
 - Vu qu'il s'agit d'une éventuelle mise à jour de prix venant de Decitre, le Jira peut-il être résolu ?
Commentaire de Anne Korchia [ 26/févr./10 15:08 ]
pour le cas du premier sbn un pro arrive à passer l'ouvrage à 12.55 euros alors que ses droits Loi Lang sont bloqués
http://bo.priceminister.com/offer/buy/86134887/van-hamme-jean-blake-et-mortimer-tome-19-la-malediction-des-trente-deniers-livre.html
Commentaire de Marion Anfreville [ 26/févr./10 15:56 ]
Je ne saurais dire si c'est le même cas de figure (histoire de MAJJ Decitre) pour cette annonce car la dernière mise à jour du produit date du 18/11/2009 et le prix d'origine est le même qu'actuellement, soit 14,50 euros.


BIBLIOGRAPHIE_2009_11_18.zip:9782870971154 9782870971154 La malédiction des trente deniers Les aventures de Blake et Mortimer Tome 19 Tome 1, Le manuscrit de Nicodemus Blake Et Mortimerµ µBelgique 287097 MDS 3019000100000 Van HammeµJeanµ1µ1µ0µµµµ ; SterneµRenéµ2µ1µ0µµµµ ; De SpiegeleerµChantalµ3µ1µ0µµµµ ; CroixµLaurenceµ4µ0µ0µµµµ 31.50 x 23.80 x 1.20 cm 0.5200 56 18/11/2009 20/11/2009 01/11/2009 20/11/2009 BD tout public Policier/Espionnage Policier/Espionnage 14.50 13.74 5.50 Album Disponible 18/11/2009


(j'ai les copies des MAJ decitre jusqu'au 15/10/2009).


Toutefois, la fiche produit a été créé par MeV FO => utilisateur "mouchtio" et a été mis à jour par la suite par Decitre.

Commentaire de Edouard Gomez-Vaez [ 08/avr./10 17:19 ]
Pour ce dernier cas, j'ai essayé de modifier l'annonce à partir du FO, et j'ai bien le message d'interdiction loi Lang.

Pourtant le prix de l'annonce a été modifiée le :

12/01/2010-00:02 Vendeur réduit prix Active Ancien prix : 12,83 Euros

Quant au produit, son prix d'origine ne semble pas avoir été modifié d'après Marion.

Ce n'est pas une histoire d'arrondi, puis que la limite Lang est à 13.78...

Je ne comprends pas ce qui s'est passé.

Commentaire de Manuel Sadok [ 26/oct./10 16:30 ]
Ben, c'est toujours d'actualité ?




[APP-27115] Mise à jour Nbre d'articles sur Home Création: 19/oct./09 18:50  Mise à jour: 29/déc./10 16:23  Résolue: 24/déc./10 10:03

Etat: Fermé
Projet: Application PriceMinister
Composants: Home Page
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 83.0.2.1

Type: Tâche Priorité: Mineur
Rapporteur: Pierre Krings Attribution: Ariane Baldinger
Résolution: Corrigé  
Σ Estimation restante: 0 minutes Estimation restante: Non spécifié
Σ Temps consacré: 10 minutes Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-27116 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Olga Costa  
APP-27117 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Marion Anfreville  
APP-27749 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Marion Anfreville  
APP-27940 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Marion Anfreville  
APP-28346 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Marion Anfreville  
APP-28842 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Marion Anfreville  
APP-29339 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Marion Anfreville  
APP-29714 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Marion Anfreville  
APP-29715 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Marion Anfreville  
APP-30011 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Ariane Baldinger  
APP-30012 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Rémi Virlouvet  
APP-30013 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Rocio Perez-Garcia  
APP-30014 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Rémi Virlouvet  
APP-30016 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Ariane Baldinger  
APP-30017 Mise à jour Nbre d'articles sur Home ... Sous-tâche Fermé Rémi Virlouvet  
Pays:
FRA - France
Projets PM: *** A PLANIFIER ***

 Description   
Vu la difficulté à afficher un nombre d'items cohérent sur la HP qui soit directement pris dans le système (en raison notamment des variations imports), il a été décidé de mettre à jour manuellement et mensuellement à partir d'un prévisionnel établi à l'avance. Charge à moi de vérifier que les chiffres sont inférieurs à la réalité des stocks (disponible dans le BI).
Le prévisionnel 2010 est donné ci-dessous et devra être mis à jour le 1er de chaque mois ou bien le 1er jour ouvrable possible suivant cette date.

01/11/2009 130 615 497
01/12/2009 134 160 787
01/01/2010 138 126 048
01/02/2010 145 995 577
01/03/2010 149 813 941
01/04/2010 153 550 510
01/05/2010 157 459 231
01/06/2010 161 021 186
01/07/2010 165 700 204
01/08/2010 167 276 038
01/09/2010 173 369 913
01/10/2010 180 395 181
01/11/2010 185 514 000
01/12/2010 192 107 828
01/01/2011 198 188 756


 Commentaires   
Commentaire de Marion Anfreville [ 28/déc./09 12:53 ]
Emplacement du label :
/default/Labels/_Navigation/FrontHeader/lbl_item_count
Commentaire de Marion Anfreville [ 28/mai/10 09:41 ]
Merci de ne pas fermer cette demande car les sous-tâches, qui sont ouvertes au fur et à mesure, vont jusqu'à 2011.
Commentaire de Ariane Baldinger [ 24/déc./10 10:03 ]
les sous-tâches ont été résolues.

Pierre,
Si tu souhaites d'autres mises à jour pourrais-tu ouvrir un nouveau jira stp ?

Merci




[APP-27973] Utilisation du filtre Last Tracking 30 jours dans les tags pour nos partenaires en Affiliation Création: 14/janv./10 14:21  Mise à jour: 10/déc./10 17:01  Résolue: 07/déc./10 19:49

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation
Affecte la/les version(s): 59.0.3
Version(s) corrigée(s): 82.0.2.2

Type: Amélioration Priorité: Majeur
Rapporteur: Jonathan Gorges Attribution: Dispatcher (Pôle CTN)
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***
Classif FONC: webanalytics

 Description   
Bonjour,

Nous avons décelé un problème en décembre dans la manière dont nous rémunérions nos partenaires en Affiliation.

Le problème:
En affiliation, nous rémunérons nos affiliés uniquement pour des paniers Last Tracking 30 jours. Ce filtre "last tracking 30 jours" est une donnée utilisée uniquement par Business Object.
Le processus de validation des ventes est aujourd'hui le suivant : nous communiquons 100% des paniers réalisés par les affiliés de chaque plateforme via leur tags, puis nous demandons aux plateformes de ne valider que les paniers "Last tracking 30 jours" en utilisant des reporting BI qui filtrent les mauvais paniers (Last tracking > 30 jours).

Nous nous sommes aperçu en Décembre que les reporting utilisés ne possédaient pas ce filtre "Last Tracking 30 jours" et donc que nous surpayions nos partenaires en leur payant des ventes dont les tracking avaient été créés plusieurs mois auparavant... Ce problème existait depuis plusieurs mois.
Sur Décembre 2009, nous avons donc éviter de payer de justesse 12.000 paniers sur 36.000 ! L'impact financier peut-être très rapidement important.

La solution:
Afin d'éviter que ce problème ne se reproduise, la solution consiste à intégrer directement le filtre "Last Tracking 30 jours" dans l'information que nous communiquons aux plateformes.

L'objectif:
Garder en base toute l'information relative aux paniers créés sur PriceMinister via l'affiliation, mais ne communiquer aux plateformes QUE les paniers "Last Tracking 30 jours". Avec cette amélioration, plus aucune erreur humaine ne sera possible.
Nous garderons les filtres "Last Tracking 30 jours" dans les rapports BI utilisés, juste par sécurité !

Les partenaires concernés:
Pour le moment, seul le canal affiliation est concerné. Les partenaires concernés sont donc : Effiliation, Zanox, Affilinet.

Je reste à votre disposition pour toute information complémentaire.

Merci d'avance pour votre retour et excellente journée.

JG

 Commentaires   
Commentaire de Fabrice Feugas [ 07/déc./10 19:49 ]
Corrigé depuis un moment :)

Ca fonctionne bien JO ?
Commentaire de Jonathan Gorges [ 08/déc./10 08:48 ]
Oui oui, cela fonctionne parfaitement.
Merci




[APP-20934] pb tracking souhait Création: 23/juin/08 15:19  Mise à jour: 13/janv./09 11:41  Résolue: 21/juil./08 18:23

Etat: Fermé
Projet: Application PriceMinister
Composants: Souhaits, Tracking
Affecte la/les version(s): 23.0.3
Version(s) corrigée(s): 38.0.0 (TX-D Bis)

Type: Bogue Priorité: Majeur
Rapporteur: Olivier Mathiot Attribution: Pierre Bret
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel QDC juin 08 wish.xls    
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***

 Description   
chute de volume d'affaire et des visites associés au tracking de souhaits observés par thomas
en VA dans BI :
2007/11 2007/12 2008/01 2008/02 2008/03 2008/04
409877,01 446175,32 451933,79 343959,2 169677,29 118085,31


analyse de quentin :
La chute correspond tres précisemment a la mise en place du sharp tracking (voir PJ)
 
http://pricejira.lan/browse/APP-19413
 
Il s'agit donc visiblement bcp + d'une chute liée à un bug dans la mesure des entrées que rééllement du VA.
 
2 options :
 
1. le sharp tracking est buggé **au niveau de la capture côté serveur**
=> je ne pense pas car on s'en serait rendu compte sur d'autres cas
=> mais si c'est ca c'est grave qu'on ne s'en soit pas rendus compte + tôt !
 
2. le sharp tracking est buggé **dans les mails** :
certains logiciels de messagerie pourraient ne pas transmettre la partie située après le # au browser lors du clic sur le lien
=> je penche plutot pour ca
 
Swan / Pierre : A creuser, tester, vérifier !!!
 
Vous pouvez mettre un Jira je pense...
 

 Commentaires   
Commentaire de Olivier Mathiot [ 23/juin/08 15:25 ]
ci joint analyse des chiffres souhaits sous XLS par QDC




[APP-19687] [CoSAV]Possibilité de limiter l'accès aux pages nécessitant d'etre logué si l'utilisateur utilise un anonymizer? Création: 20/févr./08 16:29  Mise à jour: 08/juil./09 10:36  Résolue: 02/juil./09 14:48

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 19.0.2
Version(s) corrigée(s): 49.0.0 (TX-H)

Type: Amélioration Priorité: Majeur
Rapporteur: Cedric Favero Attribution: Dispatcher (Pôle TX)
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***
Classif FONC: CoSAV

 Description   
Je pense qu'il s'agit de questions liées à la sécurité et donc concernant Ange Ferrari mais je poste le JIRA en l"état pour voire toutes les implications.

Nous constatons depuis le passage au gratuit des annonces auto une hausse importante des annonces auto frauduleuses.
Actuellement on peut estimer le nombre d'annonces frauduleuses détectées, avérées et supprimées à 10/15 par jour!
Chacune peut entrainer plusieurs milliers d'euros d'arnaque et Price etre considéré comme responsable.

Un certain nombre d'outils de surveillance ont été mis en place par mots clés , notamment sur les IP et qui fonctionnent tres bien.
Toutefois les comportements commencent à se modifier et certains fraudeurs réussissent à passer entre les premieres mailles du filet , notamment en dissimulant leur réelle adresse IP , à priori par le biais de logiciels "anonymizers" les faisant apparaitre dans d'autres pays (Allemagne , USA, etc...) alors que nous surveillons particulièrement certaines adresses (comme le Benin ou la Roumanie).

Ma question est la suivante :
serait-il possible d'envisager de bloquer l'accès aux pages du site nécessitant d'etre logué (mon compte/ mise en vente/etc... ) dans le cas où l'on détecte l'usage d'un tel logiciel anonymizer? A-ton déjà un blocage en fonction de l'usage ou non des cookies?

Saurait-on le faire et celà serait-t-il envisageable?

Merci pour tous vos éventuels retours.




 Commentaires   
Commentaire de Ange Ferrari [ 20/févr./08 16:46 ]
Cedric peux tu me montrer un exemple
d'annonce frauduleuse datant d'aujourd'hui ou d'hier
que je puisse faire des recherches pour identifier le comportement du vendeur sur le site ?
Commentaire de Cedric Favero [ 20/févr./08 16:54 ]
Exemple de compte: Ilona27
http://bo.priceminister.com/user_back?action=userview&user_account_id=15991763&show_event_login=true#events

Lors de la création de l'annonce il avait une IP que nous n'avons pas en mot clé: 78.47.210.72 (on peut en rajouter à l'infini)

Par contre par la suite on a des IP AOL ou une IP Roumanie qui nous auraient permis de tomber sur lui car on a les plages en mot clé.
Commentaire de Cedric Favero [ 20/févr./08 16:55 ]
Ou sinon j'avais aussi une personne avec un nombre important de comptes.
Tous avec le meme mot de passe: 2g6v27a (que l'on a mis en mot clé) mais avec des adresses IP à tous les coins du monde

http://bo.priceminister.com/user_back?action=usersearch&javascript_callback=&login=&password=2g6v27a&user_account_id=&last_name=&usr_type_code=&permission_type=&permission_value=false&usr_presence_code=&usr_visibility_code=&coupon_secret_name=&reliability=&email=&compensation=&usr_privilege_code=&start_date=&end_date=&start_connection=&end_connection=&ip_address=&number_rows=200&x=0&y=0
Commentaire de Ange Ferrari [ 20/févr./08 18:14 ]
en fait il est assez difficile de bloquer quelqu'un qui utilise un proxy:

pour se logger il est obligé d'accepter les cookies ( le cookie de session )

pour ce qui est de l'ip le seul controle que l'on pourrait rajouter c'est un controle sur la provenance de
l'ip qui n'est pas française en théorie un vendeur qui vend sa voiture sur price est en france ?
on possède la liste des plages d'@ ip des ISP français.

Ensuite on peut ( et on le fait déjà ) bloquer l'accès à tout ou une partie du site à une IP ( ce qui nous permet d'empêcher certains crawler )
par contre il faut qu'on récupère la liste des IP que vous bannissez
Commentaire de Cedric Favero [ 21/févr./08 13:50 ]
En fait on ne veut pas non plus bloquer complétement l'accès car du coup c'est totalement visible pour eux.
Avec notre systeme , ils ne se rendent pas obligatoirement compte que leurs annonces sont invisibles.

De plus , il faut toujours un controle humain.
ex: on met des IP Afrique en surveillance mais tout le monde a le droit d'aller en vacances au Maroc ou à l'Ile Maurice...

Je voulais juste savoir si d'une maniere ou une autre il était possible de pister une personne provenant d'un proxy ou empecher le log lorsque'on detectait l'usage d'un tel outil.
(je crois que c'est le cas sur ebay)

Après on ne mettra jamais toutes les IP en surveillance non plus...

Je suis par contre interessé par la liste des plages IP des ISP français, çà peut servir.
Et vais voir aussi si je trouve également les plages de certains relais "anonymes".

Merci.


Commentaire de Ange Ferrari [ 03/mars/08 10:50 ]
Pour les plages d'adresses IP FR

il y a une liste la

http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/FR-cidr.txt

Commentaire de Emeric Teil [ 02/juil./09 14:48 ]
L'Auto étant maintenant migrée...




[IMP-5703] Maintenance Import - HeureH : problème de référence SKU Création: 01/avr./10 10:26  Mise à jour: 05/mai/10 13:41  Résolue: 05/mai/10 13:41

Etat: Résolu
Projet: Paramétrage - Import
Composants: Demande commerciale
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Maram Khayati Attribution: Jérome Marianne
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Text File Modele_d_export_PM_pour_Bijoux-2010_03_18_11.csv     JPEG File screenshot-1.jpg     Text File Tic Tac Time - PM (Bijoux) - 10-03-2010.csv    
Pays:
FRA - France
Login: HeureH
Séparateur: N/A
Type de traitement:
N/A

 Description   
Message d'origine-----
De : thierry.vernhes@tvdistrinet.com
Envoyé : 2010-03-29 11:16:26.0
A : Priceminister
Objet : Tictactime : PB de transmission de SKU des commandes Client

Société : Tictactime
0320575333 (jerome.detre@tvdistrinet.com)

Bonjour,

Il semble qu¿il y ait eu des soucis sur plusieurs commandes passées chez vous. Les articles commandés par les clients ne sont pas ceux qu¿ils attendaient.
- 84159055 (http://www.priceminister.com/purchase?action=saleview&amp;purchaseid=84159055 )
- 84267440 (http://www.priceminister.com/purchase?action=saleview&amp;purchaseid=84267440 )

Il semble que la raison soit que les SKU que vous nous transmettez par le biais des commandes ne sont pas toujours les bons (Souvent pour des bijoux).

Dans la commande 84159055, le SKU transmis est le 80353 alors que ce devrait être 79358
Dans la commande 84267440, le SKU transmis est le 67166 alors que ce devrait être 67387 (pourtant correct dans notre inventaire PM : http://www.priceminister.com/inventory?sort=&amp;category=advert_clothing&amp;keyword=Rt-61109&amp;submitbtn=&amp;category_search_ref=advert_clothing_search_all )


En vérifiant sur d¿autres commandes, ce ne sont pas les seules, il y a aussi :

84305322
84290079
84277457
84048335
83512417
84094218
83534544

Pouvez vous jeter un ¿il assez rapidement ? Car les acheteurs sont susceptibles de recevoir des articles dont le prix ne correspond pas à ce qu¿ils paient réellement.. (Dans les 2 sens)

Cordialement,

Jérôme DETRE


 Commentaires   
Commentaire de Maram Khayati [ 08/avr./10 15:10 ]
Le pro est revenu vers moi,

Pouvez-vous faire quelque chose ?

merci
Commentaire de Jérome Marianne [ 13/avr./10 11:34 ]
Il faut demander au pro de nous envoyer son dernier fichier de création produit bijoux pour qu'on puisse voir s'il n'aurait pas réutiliser des références.
Commentaire de Maram Khayati [ 13/avr./10 11:49 ]
Envoi mail au vendeur. Support pro en copie. Merci
Commentaire de Maram Khayati [ 13/avr./10 16:42 ]
Retour du PRO par mail.

--" Voici les 2 derniers fichiers de création bijoux (généré par Neteven, notre prestataire)."

Merci
Commentaire de Jérome Marianne [ 14/avr./10 14:09 ]
Le problème vient du fait que le pro utilise des références identiques pour des produits differents. Voir un ex en copie d'écran.
Il utilise la ref 80897 pour un bijou Phebus et pour un bijou Dolce Gabbana.
Du coup 2 annonces se mettent sur la fiche produit 80897 et forcement une n'est pas bonne.
Commentaire de Jérome Marianne [ 14/avr./10 14:19 ]
Étant donné que le pro fait du multiformat et fait des maj neteven tous les jours on ne peut pas vider tout son stock et supprimer toutes ses fiches produits.

C'est donc au pro de vérifier ses références produits en doublon qui posent problèmes et de ne plus les utiliser car il y a eu des mélanges d'informations, ou alors de nous donner les références produits en doublons qui posent problème pour qu'on les supprime et repartir sur des bonnes bases pour ses prochains imports.

Il est important de sensibiliser les pros sur l'importance des références uniques.
Commentaire de Maram Khayati [ 14/avr./10 14:27 ]
J'en ai informé le PRO. J'attend donc son retour.

Merci
Commentaire de Isabelle Weisbecker [ 21/avr./10 11:26 ]
Ajout de Dorian en obseravteur pour suivi Neteven.
Commentaire de Dorian Porta Delsol [ 28/avr./10 16:27 ]
Voici le retour de Neteven :

"J'ai mis un certain temps à remonter la boucle de ce problème. J'avoue ne pas avoir compris de quoi il s'agissait à première vue car je n'étais pas dans la boucle du service paramétrage attendant un retour. Je comprend que HeureH a des erreurs de visuels dans ses annonces PM. Quelqu'un a fait une demande pour supprimer les fiches ? pas chez nous en tout cas.

Le catalogue de HeureH contient des SKU unique qui sont des déclinaisons de taille, coloris, elles-mêmes réunies sous un SKU Père.
Dans les fichiers de création, nous venons de comprendre que le marchand utilise un SKU père en tant que Référence Modèle et un SKU unique dans Référence Annonce, ce qui donne :

Référence Modèle | Référence Annonce
                               87346 87542
                               87346 87543
                               87346 87544
                               87346 87545
                               87346 87346

Penses-tu que cela puisse générer des incohérences de ton coté au moment de la publication des annonces ?
Pour rappel, la question du SKU père avait été abordé avec Skikom.

Les SKU Pères sont-il supportés par la plateforme?
Si nous déposons un fichier de création à jour avec ces mêmes SKU, les fiches présentes seront-elles écrasées?

Nous avons par sécurité clôturer les annonces Bijoux de HeureH."

Merci de ton retour Jérome.
Commentaire de Jérome Marianne [ 29/avr./10 10:36 ]
Le problème qui se pose ici est que certains SKU père identiques sont utilisés pour des produits différents, je reprend l'ex cité précédemment du SKU père 80897qui est utilisé pour un bijou Phebus et pour un bijou Dolce Gabbana.

Si le pro n'arrive pas à gérer cela il n'a qu'a prendre les références annonces qui sont uniques et les utiliser aussi pour les références modèles, comme ça on créera une fiche et une annonce par référence et cela résoudra le problème de doublons.

Commentaire de Jérome Marianne [ 05/mai/10 13:41 ]
Pour régler le souci de SKU le pro doit prendre les références annonces qui sont uniques et les utiliser aussi pour les références modèles, comme ça on créera une fiche et une annonce par référence et cela résoudra le problème de doublons.




[BCK-258] (ES) (Affiliation) Partenariats directs en Espagne - Suivi CA sur XITI par partenaire externe Création: 04/janv./11 12:06  Mise à jour: 27/janv./11 18:43

Etat: Ouvert
Projet: Backlog Projets
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Isabel Yus Attribution: Dispatcher (Pôle CTN)
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne
Projets PM: *** RESERVE ***
Classif FONC: webanalytics

 Description   
Bonjour,

Nous avons de « petits » partners avec lesquels nous pouvons quelques ventes par mois en Espagne.

Pour cela il serait intéressant de pouvoir isoler ces données séparément avec des chiffres sur les accès directs et non directs, le VA et le CA sur Xiti
- Pourquoi ? Parce qu'il s'agit de sites qui n'ont pas de tag (pixels) à nous communiquer puisqu'il s'agit de sites de contenu qui ne travaillent pas à la perf: Ils ne veulent pas non plus passer par une plateforme d'affiliation. Notre objectif en Espagne étant de les développer en tant que réseau Price «bien ciblé », nous devrions trouver le système pour isoler ces données sur XiTi.

Le problème vient du fait que sur XiTi le site de niveau 1 « tracking1 » se base sur du first_tracking et ne montre pas le CA et le VA. Pour l'instant nous avons eu juste une demande et nous sommes en train d'utiliser un rapport BI comme "sortie de secours". En revanche, il nous faudrait dans l'avenir à court terme en Espagne (2 mois maxi) un tag XiTi spécifique comme on peut le faire avec d'autres partenaires.

Nous venons d'avoir une autre demande de ce type, la première étant formulée par le site de contenu video, Ultima Game et la 2ème provenant d'un magazine culturel online appelé MySofa.

Merci d'avance pour votre réponse sur le délai de traitement de cette demande,

Isabel






 






[APP-30434] Affiliation - Changement sur les tags des plateforme d'affiliation (Effiliation - Zanox - Affilinet) afin de ne plus remonter les paniers avec un last tracking > 30 jours. Création: 15/juil./10 17:52  Mise à jour: 04/oct./10 14:53  Résolue: 23/sept./10 11:20

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 78.0.0 (CTN-TU)

Type: Amélioration Priorité: Critique
Rapporteur: Jonathan Gorges Attribution: Dispatcher (Pôle CTN)
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***
Classif FONC: monétisation

 Description   
Bonjour,

Je ressors un vieux sujet évoqué notamment en décembre 2009 dernier (APP-27767), concernant notre système de tracking en Affiliation et la notion de last tracking 30 jours.
Ce jira a pour but de mettre fin à de longues discutions inutiles entre PM et les plateformes d'affiliation concernant chaque mois des milliers de paniers pour lesquels les plateformes réclament une rémunération, alors que ces derniers ne sont pas "payables" selon notre système de tracking (car last tracking > 30 jours).

** Constat
- En affiliation, nous rémunérons aux affiliés tous les paniers trackés dont la différence entre la date d'autorisation et celle du dépôt du cookie du tracking est < ou = à 30 jours.
- Cette notion de "last tracking 30 j" est une notion BI uniquement.
- En effet, nous remontons également (via le tag de la plateforme) tous les paniers ayant un last tracking > 30 jours.
- Ces paniers sont (normalement) supprimés manuellement par nos soins via un processus manuel de validation des ventes, où nous corrigeons avec nos rapports BI tous les paniers remontés à la plateforme qui n'ont pas été capturés ou qui ont un last tracking > 30 j.

** Problème
- Chaque mois, ce sujet réapparaît et les plateformes d'affiliation nous demandent de payer des milliers de paniers ayant un LT > 30 jours... !
- Les plateformes d'affiliation réclament le payement de ces paniers car elles enregistrent de leur côté un clic affilié juste avant l'achat. Voici un exemple qui explique pourquoi :
1. Le 01 janvier 2010, un internaute clique sur une bannière d'un affilié Effiliation, se rend sur PM, se logue mais n'achète pas.
2. Nous enregistrons en base le tracking Effiliation.
3. Le 15 février, donc plus de 30 jours plus tard, le même internaute se rend directement sur PM, sans passer par un lien tracké, et achète.
4. Nous remontons la vente (le tag Effi se déclenche), mais ce panier n'est pas payable car last tracking > 30j. Il est mis « EN ATTENTE » côté Effiliation.
5. Durant sa session (session ouverte naturellement), l'internaute peut cliquer n'importe où sur la toile (chez un cashbacker, un couponneur, un emaileur)... Effiliation enregistre donc un clic de son côté, juste avant l'achat... Effiliation croit donc que ce panier doit lui être payé.
6. Cependant, notre système de tracking ne prend pas en compte ce clic, car c'est la visite directe qui a permis l'ouverture de la session. Tout ce qui se passe durant la même session ne peut venir perturber le last tracking.

** Solution
- Pour en finir avec ce sujet et mettre fin à ce discourt de sourds avec les plateformes, il serait judicieux de ne plus remonter aux plateformes (via leur tag) tous les paniers ayant un last tracking > 30 jours.
- En d'autres termes : la suppression des paniers LT > 30 jours ne doit plus se faire à postériori viaà un processus manuel de notre part, mais bien en amont. Les plateformes d'affiliation ne doivent plus remonter une seule vente ayant un LT > 30 jours.

Ce sujet étant assez sensible (car il touche à la rémunération des partenaires) et important, il serait utile de l'évoquer en CO-Market.

Je reste à votre disposition pour toute information complémentaire ou pour en parler de vive voix.

Merci d'avance pour votre retour.

Jon

 Commentaires   
Commentaire de Fabrice Feugas [ 22/juil./10 17:20 ]
En effet, ça serait judicieux d'en parler en CoMarket, via Odile.

Commentaire de Jonathan Gorges [ 18/août/10 12:04 ]
Hello,

Suite au dernier CoMarket et à la nécessité de prioriser ce Jira, j'aimerai insister sur un point en particulier qui a peut-être mal été expliqué.

Comme vous le savez, les sites éditeurs (affiliés) ont le choix parmi plus de 30.000 programmes d'affiliation en France. Plusieurs critères sont importants pour un affilié dans le choix d'un programme d'affiliation : la rémunération de l'annonceur, son taux de transfo, son panier moyen et son taux de rejet...

Les affiliés PriceMinister pensent que nous avons un taux de rejet avoisinant les 18% ! Cette considération est catastrophique et très loin de la réalité.
Ce taux est en effet "artificiellement" haut car nous remontons des milliers de ventes LT > 30 j aux plateformes que nous rejetons manuellement à posteriori durant notre processus de validation des ventes. Nous ne devrions en aucun cas inclure ces paniers inutiles de ce taux de rejet ; pourtant les plateformes et les affiliés le font...

Aussi, il n'est juste pas judicieux de notre côté de remonter des ventes (non payables) à des partenaires pour les rejeter juste après manuellement.

Ces derniers mois, nous constatons de plus en plus de retours des plateformes et des affiliés qui se plaignent du très fort taux de rejet de PriceMinister. Certains affiliés ne veulent même plus relayer le programme à cause de ces mêmes (fausses) raisons.

Ce Jira a été ouvert en priorité majeur, mais il s'agit réellement d'un problème critique et préoccupant...

N'hésitez pas à revenir vers moi si vous avez la moindre question.

Pourriez-vous svp me donner plus de visibilité sur l'avancement de ce projet ?

Par avance merci.



Commentaire de Fabrice Feugas [ 18/août/10 17:24 ]
Hello,

Merci pour ce retour très complet :).

Odile nous a rappelé l'importance de ce JIRA en CoMarket ce matin et nous allons donc le traiter rapidement, au détriment du jeu vendeur. A noter cependant, il ne sortira pas en prod avant notre prochaine version le 05/10...
Commentaire de Swan Desportes [ 23/sept./10 11:20 ]
Désormais tous les matching de promo en last tracking ne sont fait que si le LT a moins de 30 jours.
Commentaire de Cédric Goldovsky [ 04/oct./10 14:53 ]
Ok, vu avec Swan.




[BIN-362] [Espagne/Fraudes] : Rapports transactions entre comptes pour l'ESPAGNE Création: 27/août/07 13:58  Mise à jour: 23/oct./07 10:46  Résolue: 21/sept./07 15:24

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Sebastien Bruzzone Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne

 Description   
Bonjour,

Nous avons un rapport édité quotidiennement concernant les transactions entre comptes pour la France : il est dans http://intra.priceminister.com/stats/reports/public/BackOffice/ et son nom : fraud_seller_buyer_.txt.gz

En raison de fraudes similaires sur l'Espagne, nous aimerions avoir le même rapport pour ce pays.

Merci.

 Commentaires   
Commentaire de Agathe Remy [ 07/sept./07 18:49 ]
Sébastien,

Le rapport que tu utilises sur la France est généré par l'ancien système de reporting.
Hors, nous n'avons pas d'architecture équivalente pour l'Espagne.

En revanche, nous pouvons développer un rapport BusinessObjects. Dans ce cas, il faudra que je transfère ta demande dans le projet BusinessIntelligence.
Peux-tu me confirmer que cela vaut le coup que nous passions du temps à développer ce nouveau rapport dans BI?

Merci:-)

Agathe
Commentaire de Sebastien Bruzzone [ 18/sept./07 08:18 ]
Bonjour Agathe,

Oui nous avons absolument besoin de ce rapport car nous avons eu de gros problèmes de transactions entre comptes sur l'Espagne. Nous avons detecté un peu tardivement ces commandes et on aurait pu les detecter bien avant si nous avions eu le rapport pour l'Espagne.

Merci ;-)

Sébastien
Commentaire de Agathe Remy [ 18/sept./07 19:17 ]
Samir,

Voici un nouveau rapport BI qu'il faudra déployer en France et en Espagne.
cf la requête sur titan:
/data/priceminister/reporting/platform/prod/sql/sources/backoffice/fraud_seller_buyer.sql

Merci:-)
Agathe
Commentaire de Agathe Remy [ 19/sept./07 11:53 ]
Samir,

Voici la requête qui sera à implémenter dans le rapport BI :
SELECT TO_CHAR(PURCHASE.AUTHORIZATION_DATE, 'YYYY/MM/DD') ||'|'||
        PURCHASE.PURCHASE_ID ||'|'||
        ITEM.ITEM_ID ||'|'||
        CASE WHEN (ITEM.CLOSING_DATE-ITEM.COMMIT_DATE)<1 AND ITEM.CLOSING_DATE>=TRUNC(SYSDATE - 7) AND ITEM.COMMIT_DATE>=TRUNC(SYSDATE - 7)
        THEN 1
        ELSE 0
        END
FROM PURCHASE,
        ITEM,
        USER_ACCOUNT SELLER,
        USER_ACCOUNT BUYER
WHERE PURCHASE.PURCHASE_ID=ITEM.PURCHASE_ID
AND ITEM.BUYER_ACCOUNT_ID=BUYER.USER_ACCOUNT_ID
AND ITEM.SELLER_ACCOUNT_ID=SELLER.USER_ACCOUNT_ID
AND BUYER.IP_ADDRESS=SELLER.IP_ADDRESS
AND PURCHASE.PCH_STATUS_CODE IN (80, 90, 100)
AND ITEM.ITM_STATUS_CODE IN (30, 40, 70)
AND PURCHASE.AUTHORIZATION_DATE>=TRUNC(SYSDATE - 7)
AND SUBSTR(PURCHASE.IP_ADDRESS,1,7)<>'195.93.'
ORDER BY TO_CHAR(PURCHASE.AUTHORIZATION_DATE, 'YYYY/MM/DD'),
         PURCHASE.PURCHASE_ID,
         ITEM.ITEM_ID
;

Merci:-)

Agathe
Commentaire de Samir Beghdadi [ 21/sept./07 10:59 ]
Agathe,

A toi de jouer maintenant, le rapport Developement / Backoffice/Fraude - Transactions entre comptes est enfin prêt pour validation en Dev.

Merci,

samir
Commentaire de Sebastien Bruzzone [ 23/oct./07 10:44 ]
ok c'est réglé, merci




[DEC-642] [Seller macros] : Rapports vente cassé Création: 09/janv./09 19:37  Mise à jour: 25/févr./09 11:35  Résolue: 20/janv./09 18:20

Etat: Fermé
Projet: Reporting
Composants: Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Charlotte Fachan Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Il semble que les rapports vente soient cassés :
http://intra.priceminister.com/stats/reports/confid/executive/seller/macro/

le nombre de vente par mois est vraiment très très faible :-(

merci

Charlotte

 Commentaires   
Commentaire de Patrice Boulanger [ 13/janv./09 14:36 ]
Plutôt du BI non ?
Commentaire de Agathe Remy [ 13/janv./09 14:48 ]
Bonjour Thomas,

Peut-on en savoir un peu plus :
- de quel rapport(s) parlez-vous ? individual_sales_2008-Q4.txt.gz ou individual_sales_2009-Q1.txt.gz ?advert_deposit_2008-Q4.txt.gz ou advert_deposit_2009-Q1.txt.gz ? Les 2 ou les 4?
- quel est le nb de ventes moyen par mois ?

Merci.
Agathe

Commentaire de Charlotte Fachan [ 19/janv./09 11:58 ]
Bonjour Agathe,

cela concerne les rapports vente
"individual sales" et "advert deposit" de Q4 2008.
Les données s'arrêtent au 26/12.

Merci

Charlotte
Commentaire de Agathe Remy [ 19/janv./09 13:24 ]
Bonjour Charlotte,

Il ne s'agit pas d'un bug. Les rapports sont lancés chaque samedi et change de périmètre chaque trimestre.
Ainsi, si le samedi n'est pas le dernier jour du trimestre, il te manque qqs journées dans le rapport.
Thomas n'ayant jamais voulu priorisé la migration de ce rapport dans BI, nous le relançons manuellement à votre demande à chaque changement de trimestre pour récupérer les données manquantes.

A ta disposition si tu as d'autres questions.

Agathe
Commentaire de Dalila Belkebir [ 20/janv./09 18:20 ]
Bonjour Charlotte,

Les rapports ont été regénérés sur Q4 2008 (oct-nov-dec).

Merci de me valider le JIRA pour clôture.

cdlt,
Dalila.
Commentaire de Charlotte Fachan [ 22/janv./09 14:30 ]
Merci Dalila, c'est top.
par contre je dois vérifier les données sur 2007 et il me semble que les rapports sont également cassés (Q4 2007)

Merci

Charlotte
Commentaire de Dalila Belkebir [ 22/janv./09 14:45 ]
Bonjour Charlotte,

Aujourd'hui la base de données sur laquelle on récupère les infos n'est pas disponible aujourd'hui.
Je te récupère donc le Q4 2007 demain si la base est OK.

Dalila.
Commentaire de Charlotte Fachan [ 26/janv./09 17:11 ]
Salut Dalila,

est ce que les rapports sur q4 2007 ont pu être récupéré?

Merci

Charlotte
Commentaire de Dalila Belkebir [ 26/janv./09 17:14 ]
Hello Charlotte,

Le serveur n'est toujours pas disponible.
Pourtant je pense aux seller macro tous les jours .....

:-)
Dalila.
Commentaire de Dalila Belkebir [ 25/févr./09 11:35 ]
Les rapports seller macro ont été réédités.
Les rapports vont bientôt migrer dans le BI.




[EXP-4972] Extract jeu concours 1000Mercis Création: 01/oct./09 10:26  Mise à jour: 19/avr./10 17:08  Résolue: 10/mars/10 11:38

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Carole Visser Attribution: Ayoub Benseghir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File inscrits PriceMinister_Mariage 20100126.rar     Zip Archive inscrits PriceMinister_Mariage non-membres 20091217.zip     File inscrits_PriceMinister_Mariage_20100216.csv     Microsoft Excel Priorité Optin.xlsx     Microsoft Excel Tracking par idfrom.xlsx    
Pays:
FRA - France

 Description   
Bonjour,

Nous organisons avec 1000Mercis un jeu concours « Les surprises du mariage » qui débutera le 15 octobre.
Cette opération de collecte d'adresses durera environ 2 mois.

Il faudrait donc prévoir 2 extracts un au milieu du jeu et un à la fin c'est-à-dire mi-novembre et mi-décembre.

Voici le format de l'extract:
e_mail;prenom;nom;civilite;optin

A votre dispo si vous avez des questions.

Merci

Carole


 Commentaires   
Commentaire de Carole Visser [ 10/déc./09 15:44 ]
Bonjour,

Le premier extract pour le jeu concours "les surprises du mariage" est prévue pour jeudi prochain (17/12).
Eric, est ce que c'est ok pour toi??

Carole
Commentaire de Carole Visser [ 19/janv./10 14:41 ]
Bonjour Eric,

Le jeu concours "Les surprises du mariage" se termine jeudi prochain (21/01).
1000Mercis devrait nous fournir l'extract en début de semaine.

Est ce que c'est possible pour toi de l'intégrer la semaine prochaine?

Merci

Carole
Commentaire de Eric Vannier [ 19/janv./10 14:47 ]
Bonjour Carole,

Pas de soucis, ne vous loupez pas car je ne suis pas là , la semaine d'après ....

Il faut un code de tracking pour me permettre l'intégration.

Merci
Commentaire de Carole Visser [ 29/janv./10 10:48 ]
Eric,

Tu trouveras en pièces jointes un fichier .RAR contenant l'extract de l'ensemble des inscrits à l'opération « Les surprises du mariage » ainsi qu'un fichier indiquant le tracking associé à chaque idfrom.

Et voici le mot de passe pour ouvrir le fichier : mm_20100126

Cet extract contient les informations suivantes pour les 316 203 inscrits avec email valide au jeu :
- Email
- Prénom
- Nom
- Civilité
- Optin
- Date d'inscription au jeu
- Id_from

En ce qui concerne l'optin :
Oui : opt in partenaires
Oui mais pas partenaires : opt in
Non : opt out


A ta dispo si tu as des questions,

Carole

Commentaire de Eric Vannier [ 29/janv./10 14:42 ]
L'import est en cours
Commentaire de Carole Visser [ 11/févr./10 14:56 ]
Eric,

Comme vu ensemble, il faudrait modifier le first tracking des individus présents dans le premier extract de l'OP de collecte.

Il faudrait leur appliquer les mêmes first tracking par id from que pour le 2ème extract. Tu trouveras la table de correspondance en pièce jointe ainsi que le premier extract.

A ta dispo si tu as des questions,

Carole

Commentaire de Carole Visser [ 16/févr./10 12:37 ]
Eric,

Voici le mot de passe pour ouvrir le fichier premier extract : 20091218

Carole
Commentaire de Eric Vannier [ 18/févr./10 18:32 ]
Un peu de travail pour toi
Commentaire de Ayoub Benseghir [ 24/févr./10 10:47 ]
C'est fait.
Commentaire de Carole Visser [ 12/avr./10 12:17 ]
Ayoub,

Nous nous sommes aperçu avec Eric la semaine dernière qu'il y a avait eu un problème au moment de l'import des contacts de l'OP de collecte. Le batch a été stoppé et environ 150 000 personnes n'ont pas été intégrées dans la base.

Comme vu avec Eric ce matin, ces contacts sont désormais dans la base PM.

Il faudrait maintenant leur attribuer le bon first tracking (cf. pièces jointes).

A ta dispo si tu as des questions,

Merci

Carole
Commentaire de Ayoub Benseghir [ 12/avr./10 14:11 ]
c'est fait.
Commentaire de Carole Visser [ 12/avr./10 14:14 ]
Merci!
Commentaire de Carole Visser [ 15/avr./10 17:30 ]
Eric,

C'est bizarre, les personnes avec le first tracking 2285844 n'apparaissent toujours dans les rapports BI sur les first tracking.

Est-ce que tu as vérifié dans la base que tout était ok ?

Merci

Carole
Commentaire de Ayoub Benseghir [ 15/avr./10 17:48 ]
Le first tracking 2285844 n'apparait pas dans le fichier que tu nous as fourni. A ta dispo pour en discuter.

Ayoub
Commentaire de Ayoub Benseghir [ 15/avr./10 17:50 ]
On vient de comprendre.... On a mis les idfrom au lieu des first tracking (on avait raté l'épisode sur les correspondances) Je m'en occupe au plus vite
Commentaire de Carole Visser [ 15/avr./10 18:36 ]
Tu penses que ça pourra être fait pour quand?
Commentaire de Ayoub Benseghir [ 16/avr./10 10:12 ]
Dans la matinée :)
Commentaire de Carole Visser [ 19/avr./10 11:51 ]
Est ce que c'est ok pour les tracking?
Commentaire de Ayoub Benseghir [ 19/avr./10 11:53 ]
C'est bon pour nous, qu'est ce que les rapports BI te disent?
Commentaire de Carole Visser [ 19/avr./10 17:08 ]
C'est bon, tous les first tracking apparaissent dans les rapports BI.

Merci

Carole




[BIN-645] [Sales] : Rapport par requete SQL sur ventes de lots sur Price Création: 13/janv./10 13:21  Mise à jour: 16/mars/10 17:41  Résolue: 16/mars/10 17:24

Etat: Fermé
Projet: Business Intelligence
Composants: Sales
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Gaël Seguillon Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Comme vu avec Dalila hier et dans le cadre du projet de la mise en place de type de produits lots sur PM, je cherche à avoir des informations sur les transactions effectuées sur ce type de produit sur le site.
La recherche doit être faite par mots clés du titre (lot ou lots)
Par ailleurs si c'est possible on peut aussi récupérer les données concernant les fiches produits sur lesquelles figurent l'attribut conditionnement lot (produits concernés : timbres, cartes principalement)
Dans cet extrait j'aurai besoin,
un global autorisé VA/commission/nbre d'articles, fdp moyen/prix moyen article sur les 3 derniers mois
et un détail des ventes avec titre, type de produit, frais de port associé
à votre dispo pour plus d'infos
Gaël

 Commentaires   
Commentaire de Cyril Tanneau [ 18/janv./10 14:25 ]
Gaël,

Au sujet de ta demande, je te propose que nous procédions en deux temps.

Un premier lot consisterait à extraire pour les produits dont le titre contient "lot" ou "lots" les indicateurs financiers suivants:
- le nombre de produits
- le nombre d'articles autorisés,
- Le VA ,
- La commission PM,
- Les frais de port moyens,
- le prix moyen de l'article

Cet extract concerne les articles autorisés au cours des trois derniers mois et l'extract sera organisé par famille de produits.

Dans un second temps, si les chiffres sortis sont concluants, nous pourrons passer à un second extract plus détaillé.

Est-ce que cela te convient?

J'attends ton GO pour lancer l'nanalyse.

merci,

Cyril
Commentaire de Gaël Seguillon [ 18/janv./10 19:31 ]
ca me semble parfait on peut démarrer ainsi
merci Cyril !
Commentaire de Cyril Tanneau [ 25/janv./10 11:41 ]
Gaël,

nous avons généré l'extract conformément à ta demande. Tu trouveras le fichier Excel dans le répertorie suivant:

T:\BI\01 - Demandes ponctuelles\05 - Études commerciaux\2010-01 Extract Gaël ventes par lot(s) - Jira bin-645

Périmètre:
- L'étude porte sur les produits contenant 'lot' ou 'lots' dans le titre, exceptés les anglicismes 'a lot of' ou 'lots of'. (Pas maillot ni lotterie)
- On suit les articles autorisés au cours des 3 derniers mois

Indicateurs suivis:
- NB_PRODUITS : Nombre distinct de produits
- NB_ARTICLES : Nombre distincts d'articles autorisés
- VA_TTC_AUTORISÉ : Volume d'affaires TTC autorisé avec garanties et frais de port
- COMMISSION_CAPTUREE : Commission totale PM capturée (avec frais de port et garanties)
- FRAIS_PORT_MOYEN: Frais de port moyens TTC payés par les PriceMembers (Somme Frais_Port / NB items)
- PRIX_MOYEN_ARTICLE : Prix moyen de vente de l'article (item_cost_price)

Peux-tu nous faire un retour sur la demande une fois les chiffres analysés et nous préciser s'il faut générer un lot2?

Merci et bonne journée,

Cyril
Commentaire de Gaël Seguillon [ 25/janv./10 18:18 ]
j'ai vu le résultat c'est nickel merci à priori ces données sont suffisantes pas forcément besoin de lot 2
Gaël
Commentaire de Gaël Seguillon [ 01/févr./10 10:19 ]
plus pour le suivi SAV il faudrait pouvoir obtenir les données suivantes, taux de claims sur les fiches de lots

Le nombre d'annonces actives en lignes (détail par catégorie comme sur le volume vendu) comportant le mot lot, est aussi une information intéressante
celà nous permet de calculer le taux de conversion de ces annonces de lot
merci
Gaël
Commentaire de Cyril Tanneau [ 04/févr./10 15:02 ]
Gaël,

Pas de problème quant au calcul des réclamations rapportées sur ces produits. Je créé deux colonnes, une avec le nombre total de réclamations, une autre avec le nombre de réclamations acceptées.

Au sujet du nombre d'annonces actives (visibles), je ne peux que sortir le nombre d'annonces actives à ce jour, je ne peux pas remonter cette informations sur les six derniers mois car cette information n'est pas historisée dans le BI, ce qui peut fausser ton taux de conversion. Qu'en penses-tu?

Merci,

Cyril
Commentaire de Gaël Seguillon [ 04/févr./10 15:17 ]
sur les annonces actives oui c'est plus un état des lieux à aujourd'hui qui'il nous faut
merci
Gaël
Commentaire de Cyril Tanneau [ 23/févr./10 17:39 ]
Salut Gaël,

suite aux informations supplémentaires que tu as demandé, j'ai lancé la génération d'un second extract qui permet de renseigner:
     - le nombre distinct de réclamations sur les articles autorisés
     - le nombre distinct de réclamations acceptées sur les articles autorisés
     - le nombre d'annonces visibles et actives associées aux fiches produits du périmètre (ventes par lots, 3 derniers mois...)
--> L'étude se base sur le même périmètre que celui décrit ci-dessus.

Tu trouveras le second extract dans le dossier
T:\BI\01 - Demandes ponctuelles\05 - Études commerciaux\2010-01 Extract Gaël ventes par lot(s) - Jira bin-645 sous le nom V2_Extract_Ventes_par_lots.xls

Pour info, l'extract date du 05/02/2010.

Merci de valider la demande si cela te convient,

Bonne fin de journée,

Cyril
Commentaire de Cyril Tanneau [ 16/mars/10 17:24 ]
Gaël,

peux-tu valider la demande s'il te plait?

merci,

Cyril
Commentaire de Gaël Seguillon [ 16/mars/10 17:31 ]
désolé en fait j'avais déjà vu le fichier mais pas mis de commentaire
c'est tout bon pour moi
merci
Gaël




[EXP-677] Mise à jour du KERNEL sur les différents SA 32 bits de la plateforme Création: 23/déc./05 15:28  Mise à jour: 25/juin/07 18:55  Résolue: 20/févr./06 12:05

Etat: Résolu
Projet: Exploitation
Composants: Evolution
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Sébastien Tournay Attribution: Ranto Andriambololona
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   

Plannifier avec JMH via différentes MAI une mise à jour du KERNEL sur les SA 32 bits en PROD. Le but est d'arriver au même niveau de kernel que sur TELLUS dans le cadre du projet BI.

ATTENTION à bien plannfier les interventions et de communiquer au moment ou Jet s'apprête à rebooter les serveurs. On peut le faire en journée à condition de sortir les SA du pool.


[pmas@parques priceminister]$ for i in parques esculape tellus venus hercule neptune junon; do ssh pmas@$i uname -a;done
Linux parques 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux
Linux esculape 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux
Linux tellus 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55 EDT 2005 i686 i686 i386 GNU/Linux
Linux venus 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux
Linux hercule 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux
Linux neptune 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux
Linux junon 2.4.21-32.ELsmp #1 SMP Fri Apr 15 21:17:59 EDT 2005 i686 i686 i386 GNU/Linux


 Commentaires   
Commentaire de Ranto Andriambololona [ 04/janv./06 15:50 ]
Une MEP a été ouverte chez JET (MEP-005044) dans laquelle on programme la MAJ de VENUS ce Lundi 09 janvier 2006.
Il doivent m'appeller avant (cette semaine) pour bien identifier le besoin et confirmer le timing
Commentaire de Ranto Andriambololona [ 31/janv./06 11:24 ]
Nouveau plalling proposé à JET

07/02 - Parques

14/02 - Hercule

21/02 - Junon

28/02 - Neptune

07/03 - Titan
Commentaire de Ranto Andriambololona [ 31/janv./06 15:20 ]
Validé par JET (JL Blaise) et le bureau technique

07/02 - Hercule
14/02 - Junon

Commentaire de Ranto Andriambololona [ 08/févr./06 17:10 ]
Nouveau planning

16/02 - Hercule
21/02 - Junon







[APP-22596] Transformation de mémos en souhaits?! Création: 15/oct./08 14:31  Mise à jour: 13/janv./09 11:58  Résolue: 28/nov./08 14:24

Etat: Fermé
Projet: Application PriceMinister
Composants: Souhaits
Affecte la/les version(s): 31.0.1
Version(s) corrigée(s): 38.0.0 (TX-D Bis)

Type: Bogue Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Emeric Teil
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File Article_Memo_Dispo.jpg     JPEG File Article_Memo_Plus_Dispo.jpg    
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***

 Description   
Lors de la mise en place du BI Souhait, nous avons constaté qu'il arrive qu'un mémo puisse être transformé en souhait (wsh_type_code=30 => 10) , ce qui ne semble correspondre à aucune règle de gestion. Cela correspond à un évènement « UPDATE » (wse_type_code=20).

Cela nous pose un problème pour nos dénormalisations, notamment le calcul de la date de 1er dépôt d'un souhait qui peut donc varier...
Nous aurions donc besoin de comprendre comment et pourquoi cela peut arriver.

Voici un exemple identifié grâce au décalage entre l'Integ et la Prod :
Intég :
wish_id;buyer_account_id;product_id;creation_date;change_date;wsh_status_code;wsh_type_code;last_mail_date;is_removed_after_buy;buy_price;currency_id;adv_quality_code;seller_score;prd_type_code;prd_medium_code;prd_line_key;prd_model_key;selection_date;advert_id;complement_product_id;row_version
19703780;2929071;4709600;16/05/2008 11:08:06;16/05/2008 11:08:06;10;30;;1;;978;;;1140;;;;16/05/2008 10:37:29;;;1
Prod :
wish_id;buyer_account_id;product_id;creation_date;change_date;wsh_status_code;wsh_type_code;last_mail_date;is_removed_after_buy;buy_price;currency_id;adv_quality_code;seller_score;prd_type_code;prd_medium_code;prd_line_key;prd_model_key;selection_date;advert_id;complement_product_id;row_version
19703780;2929071;4709600;16/05/2008 11:08:06;18/09/2008 11:38:05;10;10;11/09/2008 11:38:05;1;130;978;;;1140;;;;16/05/2008 10:37:29;;;2

Merci.
Agathe




 Commentaires   
Commentaire de Emeric Teil [ 20/oct./08 16:07 ]
Il est fonctionnellement voulu qu'un article mémorisé puisse devenir un souhait : dans le cas où l'article n'est plus disponible, on propose alors à l'utilisateur de transformer son article mémorisé en souhait. C'est ce qui ce passe dans l'exemple fourni.

cf capture d'écran




[EXP-882] Mise à jour du DNS interne Création: 13/janv./06 16:09  Mise à jour: 25/juin/07 18:55  Echéance: 16/janv./06 00:00  Résolue: 16/janv./06 14:39

Etat: Résolu
Projet: Exploitation
Composants: Evolution
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Sébastien Tournay Attribution: Pap Ndiaye
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 1 heure
Estimation originale: 1 heure


 Description   
On a besoin pour différentes taches (FAST, BI, exploit via ARKOON) de renseigner au niveau de notre DNS interne le nom des serveurs de production avec leur adresse privée sur le réseau JMH.

au même titre que nous avons fastadmin.jmh.lan > 10.150.28.78, il nous faut cela pour tous les serveurs de prod

Il faudrait donc ajouter dans notre zone

amphitrite.jmh.lan=amphitrite=10.150.28.83
terra.jmh.lan=terra=10.150.28.82
sol.jmh.lan=sol=10.150.28.81
esculape.jmh.lan=esculape=10.150.28.67
mercure.jmh.lan=mercure=10.150.28.69
venus.jmh.lan=venus=10.150.28.70
tellus.jmh.lan=tellus=10.150.28.73
saturne.jmh.lan=saturne=10.150.28.68
parques.jmh.lan=parques=10.150.28.75
titan.jmh.lan=titan=10.150.28.80
jupiter.jmh.lan=jupiter=10.150.28.76
hercule.jmh.lan=hercule=10.150.28.77
neptune.jmh.lan=neptune=10.150.28.78=fastadmin.jmh.lan
junon.jmh.lan=junon=10.150.28.74
angita.jmh.lan=angita=10.150.28.84
aurore.jmh.lan=aurore=10.150.28.85
orcus.jmh.lan=orcus=10.150.28.87
janus.jmh.lan=janus=10.150.28.77.89
latone.jmh.lan=latone=10.150.28.88
cupidon.jmh.lan=cupidon=10.150.28.65
phaeton.jmh.lan=phaeton=10.150.28.72
graces.jmh.lan=graces=10.150.28.71
bacchus.jmh.lan=bacchus=10.150.28.79




[IMP-2665] création profil d'import avec création/maj annonces et création produit pour le partenaire ajmtrader Création: 01/oct./08 17:26  Mise à jour: 30/oct./09 15:50  Résolue: 09/oct./08 10:47

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Robin Dohin Attribution: Fotigui Tangara
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Text File errors_newinventory_ajmtrader.txt     Text File inventory_ajmtrader.txt     Microsoft Excel mapping_ajmtrader.xls     Text File monsoon-inventory 29-09a.txt     Text File newinventory_ajmtrader.txt    
Pays:
FRA - France
Login: ajmtrader
Séparateur: Tabulation
Type de traitement:
Mise à jour/création annonces avec création produits (écrasement)

 Description   
création profil d'import avec création/maj annonces et création produit pour le partenaire ajmtrader
fichier au format du pro

colonne A : ne pas importer
colonne B : référence vendeur 1
colonne C : référence vendeur 2
colonne D : code ASIN à importer en tant qu'ID produit (utile pour les futurs imports)
colonne E : code ISBN
colonne F : ne pas importer
colonne G : ne pas importer
colonne H : titre
colonne I : quantité
colonne J : état (cf mapping)
colonne K : prix en livres sterling (multiplier par 1.273 pour avoir le prix en euros)
colonne L : Collection ("True" = C)
colonne M : ne pas importer
colonne N : commentaire annonce (supprimer la mention"box + xx" en fin de cellule) / commentaire privé : "box + xx" en fin de cellule
colonne O : ne pas importer
colonne P : ne pas importer
colonne Q : ne pas importer
colonne R : ne pas importer
colonne S : ne pas importer
colonne T : ne pas importer
colonne U : ne pas importer
colonne V : ne pas importer
colonne W : ne pas importer
colonne X : ne pas importer
colonne Y : ne pas importer
colonne Z : ne pas importer
colonne AA: ne pas importer
colonne AB: ne pas importer
colonne AC: ne pas importer
colonne AD: ne pas importer
colonne AE: auteur
colonne AF: Format (cf mapping)
colonne AG: ne pas importer
colonne AH: code EAN
colonne AI: ne pas importer
colonne AJ: épaisseur en centimètres
colonne AK: ne pas importer
colonne AL: ne pas importer
colonne AM: ne pas importer
colonne AN: ne pas importer
colonne AO: ne pas importer
colonne AP: ne pas importer
colonne AQ: ne pas importer
colonne AR: ne pas importer
colonne AS: ne pas importer
colonne AT: ne pas importer
colonne AU: ne pas importer
colonne AV: ne pas importer
colonne AW: Longueur (en centimètres)
colonne AX: ne pas importer
colonne AY: ne pas importer
colonne AZ: Nombre de pages
colonne BA: Date de publication : deux modèles de dates (AAAA-MM et JJ/MM/AAAA)
colonne BB: Editeur
colonne BC: ne pas importer
colonne BD: ne pas importer
colonne BE: ne pas importer
colonne BF: ne pas importer
colonne BG: ne pas importer
colonne BH: ne pas importer
colonne BI: ne pas importer
colonne BJ: ne pas importer
colonne BK: ne pas importer
colonne BL: ne pas importer
colonne BM: ne pas importer
colonne BN: poids (en kilogrammes)
colonne BO: Largeur (en centimètres)


Classification par défaut pour la création de fiches produits :
Classification Decitre 1: littérature étrangère
Classification Decitre 2 : littérature anglo-saxonne
Classification Decitre 3 : littérature anglo-saxonne





 Commentaires   
Commentaire de Robin Dohin [ 01/oct./08 17:26 ]
fichier du pro
Commentaire de Robin Dohin [ 01/oct./08 17:27 ]
mapping état/format
Commentaire de Fotigui Tangara [ 03/oct./08 10:14 ]
Demande en cours...
Commentaire de Fotigui Tangara [ 03/oct./08 14:59 ]
Les outils d'import, en terme de nombre de colonnes sont limités à 50 colonnes. Le fichier du pro présente 66 colonnes.

Données importante au-delà de la 50ème colonne :

 - Date de parution
 - Editeur
 - Nombre de pages.

Dans un premier temps j'ai passé le fichier en Mise à jour/création annonces.
Commentaire de Fotigui Tangara [ 06/oct./08 13:30 ]
Souhaitez-vous une réorganisation des colonnes du fichier ? Cela nous permettra de pouvoir créer des produits et annonces associées.
Commentaire de Fotigui Tangara [ 06/oct./08 13:56 ]
Vu avec Robin : Il prendra contact avec le PRO en vue d'apporter une modification au fichier de ce dernier.
Je ferme la demande d'ici là. Elle pourra être réouvert pour une éventuelle création de produits et annonces associées.
Commentaire de Robin Dohin [ 06/oct./08 14:21 ]
Vu avec le pro : il utilisera dorénavant ce format de fichier avec un nombre de colonnes réduit :
ci-joint le nouveau fichier du pro

colonne A : ne pas importer
colonne B : référence vendeur 1
colonne C : référence vendeur 2
colonne D : code ASIN à importer en tant qu'ID produit (utile pour les futurs imports)
colonne E : code ISBN
colonne F : ne pas importer
colonne G : ne pas importer
colonne H : titre
colonne I : quantité
colonne J : état (cf mapping)
colonne K : prix en livres sterling (multiplier par 1.273 pour avoir le prix en euros)
colonne L : Collection ("True" = C)
colonne M : ne pas importer
colonne N : commentaire annonce (supprimer la mention"box + xx" en fin de cellule) / commentaire privé : "box + xx" en fin de cellule
colonne O : ne pas importer
colonne P : ne pas importer
colonne Q : ne pas importer
colonne R : ne pas importer
colonne S : ne pas importer
colonne T : ne pas importer
colonne U : ne pas importer
colonne V : ne pas importer
colonne W : ne pas importer
colonne X : ne pas importer
colonne Y : ne pas importer
colonne Z : ne pas importer
colonne AA: ne pas importer
colonne AB: ne pas importer
colonne AC: ne pas importer
colonne AD: ne pas importer
colonne AE: auteur
colonne AF: Format (cf mapping)
colonne AG: ne pas importer
colonne AH: code EAN
colonne AI: ne pas importer
colonne AJ: épaisseur en centimètres
colonne AK: ne pas importer
colonne AL: Longueur (en centimètres)
colonne AM: ne pas importer
colonne AN: ne pas importer
colonne AO: Nombre de pages
colonne AP: Date de publication : deux modèles de dates (AAAA-MM et JJ/MM/AAAA)
colonne AQ: Editeur
colonne AR: poids (en kilogrammes)
colonne AS: Largeur (en centimètres)
Commentaire de Robin Dohin [ 06/oct./08 14:21 ]
nouveau fichier du partenaire ajmtrader
Commentaire de Fotigui Tangara [ 06/oct./08 15:32 ]
Excel a "massacré" les EAN :-) !!!!
Commentaire de Robin Dohin [ 06/oct./08 16:15 ]
Les EAN ont été modifiés et "démassacrés"...
Commentaire de Robin Dohin [ 06/oct./08 16:15 ]
un nouveau fichier a été joint avec les EAN modifiés
Commentaire de Fotigui Tangara [ 07/oct./08 15:54 ]
Le fichier passe à 57%, je te mets le fichier d'erreurs.
Commentaire de Fotigui Tangara [ 07/oct./08 15:54 ]
Le fichier passe à 57%, je te mets le fichier d'erreurs en PJ.
Commentaire de Robin Dohin [ 08/oct./08 14:38 ]
Vu avec le pro :

est-il possible d'augmenter les prix lorsque ceux-ci sont trop bas pour qu'ils atteignent le minimum de 0.90 ¿?
Commentaire de Robin Dohin [ 08/oct./08 16:14 ]
le partenaire a finalement augmenté lui même ses prix. merci de ne pas tenir compte du commentaire précédent.




[IMP-3044] création profil d'import avec création/maj annonces et création produit pour le partenaire ajmtraderuk Création: 06/janv./09 10:30  Mise à jour: 30/oct./09 15:52  Résolue: 20/janv./09 11:51

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Jeremy Pallot Attribution: Daniel Pintamalli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Text File pmuk-monsoon export 05-01.txt    
Pays:
GBR - Royaume Uni
Login: ajmtraderuk
Séparateur: Tabulation
Type de traitement:
Mise à jour/création annonces avec création produits (écrasement)

 Description   
création profil d'import avec création/maj annonces et création produit pour le partenaire ajmtrader
fichier au format du pro

colonne A : ne pas importer
colonne B : référence vendeur 1
colonne C : référence vendeur 2
colonne D : code ASIN à importer en tant qu'ID produit (utile pour les futurs imports)
colonne E : code ISBN
colonne F : ne pas importer
colonne G : ne pas importer
colonne H : titre
colonne I : quantité
colonne J : état (cf mapping)
colonne K : prix en livres sterling (multiplier par 1.273 pour avoir le prix en euros)
colonne L : Collection ("True" = C)
colonne M : ne pas importer
colonne N : commentaire annonce (supprimer la mention"box + xx" en fin de cellule) / commentaire privé : "box + xx" en fin de cellule
colonne O : ne pas importer
colonne P : ne pas importer
colonne Q : ne pas importer
colonne R : ne pas importer
colonne S : ne pas importer
colonne T : ne pas importer
colonne U : ne pas importer
colonne V : ne pas importer
colonne W : ne pas importer
colonne X : ne pas importer
colonne Y : ne pas importer
colonne Z : ne pas importer
colonne AA: ne pas importer
colonne AB: ne pas importer
colonne AC: ne pas importer
colonne AD: ne pas importer
colonne AE: auteur
colonne AF: Format (cf mapping)
colonne AG: ne pas importer
colonne AH: code EAN
colonne AI: ne pas importer
colonne AJ: épaisseur en centimètres
colonne AK: ne pas importer
colonne AL: ne pas importer
colonne AM: ne pas importer
colonne AN: ne pas importer
colonne AO: ne pas importer
colonne AP: ne pas importer
colonne AQ: ne pas importer
colonne AR: ne pas importer
colonne AS: ne pas importer
colonne AT: ne pas importer
colonne AU: ne pas importer
colonne AV: ne pas importer
colonne AW: Longueur (en centimètres)
colonne AX: ne pas importer
colonne AY: ne pas importer
colonne AZ: Nombre de pages
colonne BA: Date de publication : deux modèles de dates (AAAA-MM et JJ/MM/AAAA)
colonne BB: Editeur
colonne BC: ne pas importer
colonne BD: ne pas importer
colonne BE: ne pas importer
colonne BF: ne pas importer
colonne BG: ne pas importer
colonne BH: ne pas importer
colonne BI: ne pas importer
colonne BJ: ne pas importer
colonne BK: ne pas importer
colonne BL: ne pas importer
colonne BM: ne pas importer
colonne BN: poids (en kilogrammes)
colonne BO: Largeur (en centimètres)

Attention création de produit pour les articles qui ne possédent pas de ISBN

 Commentaires   
Commentaire de Jeremy Pallot [ 19/janv./09 13:29 ]
Ne pas multiplier le prix par 1.27, il mettre en ligne des prix en £ avec frais de port.
Commentaire de Daniel Pintamalli [ 20/janv./09 11:00 ]
Import en cours.

Le traitement est en 'mise à jour/création d'annonces' car les classifications thématiques ne sont pas exploitables.

http://bouk.priceminister.jmh/datafile_back?action=advfilesearch&file_id=5956449&login=&process_code=&status=&use_proc_date=false&start_date=20%2F01%2F2009&end_date=20%2F01%2F2009&order=&x=0&y=0
Commentaire de Daniel Pintamalli [ 20/janv./09 11:50 ]
Le fichier passe à 66%.

Rapport d'erreurs:

No product could be found with this reference number. => 1788 lignes
The 'Condition [cell 50299]' column is compulsory => 10 lignes
The price for this item cannot exceed £XX.XX. => 795 lignes
The 'Quantity [cell 50300]' column is compulsory => 34 lignes
You cannot create a listing with a quanitity of 0. => 27 lignes




[APP-10462] Pb de déploiement sur les pages pseudo-statiques Création: 13/juin/06 15:13  Mise à jour: 25/juin/07 18:40  Résolue: 13/juin/06 15:34

Etat: Fermé
Projet: Application PriceMinister
Composants: Infrastructure
Affecte la/les version(s): 9.0.0.1
Version(s) corrigée(s): 9.0.0.1

Type: Bogue Priorité: Critique
Rapporteur: Christophe Garcia Attribution: Pap Ndiaye
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
[adminpm@deutz conf]$ pmapacheconfswitch
Switching configuration file
/etc/init.d/httpd restart: httpd restarted
Apache is now running with the production configuration.
Updating static pages...Starting with sleeptime = 0
www.pm.lan:www:..mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-www/auto-moto.newtemp': Aucun fichier ou répertoire de ce type
.............. done
voiture.pm.lan:voiture:................ done
virginmega.pm.lan:virginmega:................ done
tiscalibe.pm.lan:tiscalibe:................ done
test.pm.lan:test:................ done
rueducommerce.pm.lan:rueducommerce:................ done
rfm.pm.lan:rfm:................ done
preview.pm.lan:preview:................ done
presencepc.pm.lan:presencepc:................ done
pcdirect.pm.lan:pcdirect:................ done
ofup.pm.lan:ofup:................ done
mobilokaz.pm.lan:mobilokaz:................ done
mobilesachat.pm.lan:mobilesachat:................ done
m6.pm.lan:m6:................ done
m6net.pm.lan:m6net:................ done
m6music.pm.lan:m6music:................ done
m6game.pm.lan:m6game:................ done
liberation.pm.lan:liberation:.. done
koobuycity.pm.lan:koobuycity:................ done
jeuxvideo.pm.lan:jeuxvideo:................ done
freesurf.pm.lan:freesurf:................ done
francemobiles.pm.lan:francemobiles:................ done
europe2.pm.lan:europe2:................ done
epik.pm.lan:epik:................ done
eglue.pm.lan:eglue:................ done
croix-rouge.pm.lan:croix-rouge:................ done
cinenow.pm.lan:cinenow:................ done
camif.pm.lan:camif:................ done
bo.pm.lan:bo:................ done
bi.pm.lan:bi:................ done
bambinoccasion.pm.lan:bambinoccasion:................ done
akamai.pm.lan:akamai:../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/accueil.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/accueil.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/auto-moto.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/auto-moto.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/livres-bd.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/livres-bd.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/musique-cd.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/musique-cd.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/video-dvd-vhs.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/video-dvd-vhs.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/jeux-video.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/jeux-video.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/telephone-pda.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/telephone-pda.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/informatique-logiciels.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/informatique-logiciels.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/image-son.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/image-son.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/voyages.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/voyages.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/bargain.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/bargain.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/electromenager.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/electromenager.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/enfants-jeux-jouets.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/enfants-jeux-jouets.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/mode-textile.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/mode-textile.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/vins-saveurs.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/vins-saveurs.newtemp': Aucun fichier ou répertoire de ce type
../Pseudo-static-pages-script.sh: line 17: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/loisirs-sports.newtemp: Aucun fichier ou répertoire de ce type
mv: ne peut évaluer `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-akamai/loisirs-sports.newtemp': Aucun fichier ou répertoire de ce type
 done
acf.pm.lan:acf:................ done





[APP-15131] [CoSAV] Conservation des 6 premiers chiffres de la cb Création: 15/févr./07 18:22  Mise à jour: 20/févr./09 15:53  Résolue: 05/févr./09 10:03

Etat: Fermé
Projet: Application PriceMinister
Composants: Paiement
Affecte la/les version(s): 12.0.2
Version(s) corrigée(s): 41.0.0 (TX-E)

Type: Amélioration Priorité: Majeur
Rapporteur: Steven Harel Attribution: Fabien Bourdoulous
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à EXP-3199 mise à jour plages de ecb Ré-ouvert
Pays:
ALL - Tous
Site: Prod
Projets PM: *** RESERVE ***
Classif1: TX
Classif2: paiement
Classif FONC: CoSAV

 Description   
l'apparition des ecb a provoqué une grosse faille dans l'utilisation des coupons

actuellement, nous validons les paniers avec coupon 1er achat et coupon parrainage filleul
uniquement si le numéro de carte n'a pas été utilisé par le passé

cependant, les numéros de ecb sont uniques et donc jamais utilisées par le passé
une personne peut donc utiliser autant de coupon qu'elle a de ecb
il suffit qu'elle crée autant de comptes

sauf si les plages de ecb sont renseignées dans le système par l'exploit

le problème est qu'on n'a pu se procurer qu'une partie des plages
il y a bcp de fraude sur les plages qui nous manquent

le dernier qu'on a attrapé avait utilisé pour 15000 euros de coupons

l'idée est de constituer nous-même nos plages de ecb

les plages de ecb sont définies par les 6 premiers chiffres
et actuellement nous ne conservons que les 4 premiers

si nous conservons les 6 premiers chiffres
nous pourrons alors demander un rapport :
- des 6 premiers chiffres de la carte bancaire,
- pour les transactions pour lesquelles l'acheteur a déclaré avoir utilisé une ecb.

et identifier ainsi les plages de ecb et mettre à jour le système régulierement



 Commentaires   
Commentaire de Sébastien Aubert [ 27/juin/07 17:43 ]
Aucun soucis légal, vu avec Benoit Tabaka.
L'objectif est donc de récupérer, au lieu des 4 premiers et 2 derniers chiffre de la CB, les 6 premiers et toujours les 2 derniers.
Commentaire de Arnaud Forgues [ 28/juin/07 19:02 ]
il serait pas mal de faire une petite analyse des impacts potentiels d'une telle modif. Par exemple le fait que tous les mots clefs qui se servent actuellement du champs "$purchase.CardNumberBegin" seront éventuellement buggés si ils sont exploité de la manière suivante : "$purchase.CardNumberBegin == "0000"". Il faudra remplacer le mot clef par "$purchase.CardNumberBegin.startsWith("0000")"

Il faudra également modifier l'écran BO panier qui affiche ces informations là. Et sinon il faudra s'assurer qu'on n'a pas d'impact sur le paiement par 1euro.com qui se sert aujourd'hui de ce champs pour stocker les 4 premiers chiffres du numero de compte 1euro des utilisateurs payant par ce moyen de paiement.

Voilou pour quelques idées qui me viennent là comme ça mais il y a peut etre d'autres ...
Commentaire de Cedric Favero [ 25/sept./07 14:56 ]
Les fraudes ont un besoin assez important de cette affichage des 6 premiers numéros de carte afin de constituer un fichier de plages ECB et pouvoir les enregistrer en dur dans le système en les transmettant à l'exploit (cf JIRA lié).

Est-il envisageable de pousser un peu cette demande qui est réelement critique pour la prévention des fraudes aux coupons?
Commentaire de Steven Harel [ 25/sept./07 15:40 ]
c'est vraiment critique, j'aimerais vraiment qu'on avance sur cette demande
sans cette info, on est incapables de faire face aux fraudes massives aux coupons
pour les banques françaises ET pour les banques européennes
et une fraude massive c'est plusieurs milliers d'euros (15.000 pour le plus gros cas)
soit une partie significative du budget coupons du marketing
Commentaire de Benoit Tabaka [ 19/déc./08 16:57 ]
Comme le sujet est revenu récemment suite à plusieurs fraudes, il faudra sans doute voir pour pousser un peu la demande.

Comme je l'avais dit à Sébastien, il n'y a pas de pb légal à avoir une conservation des 6 + 2 chiffres de la CB (car ça fait ensuite 1 chance sur 1 milliard de recomposer le bon numéro de CB !).
Commentaire de Emeric Teil [ 19/déc./08 17:46 ]
OK, donc à prioriser en regard des autres demandes CoSAV.
Commentaire de Emeric Teil [ 02/févr./09 18:42 ]
Comme vu ensemble, faire au préalable une analyse technique des impacts...
Commentaire de Cedric Favero [ 03/févr./09 10:28 ]
Petit élément supplementaire, au délà de l'affichage en BO, saura-t-on avoir accès à ce 5e et 6 chiffre dans le BI ?
Et si oui est-ce que ce sera rétroactif? (en clair est-ce que les infos ont toujours "été là" et seulement masquées?).
Merci.
Commentaire de Arnaud Forgues [ 03/févr./09 11:22 ]
On saura effectivement avoir accès à ces 5e et 6e chiffres dans le BI comme dans les mots clefs en velocity. D'ailleurs, comme évoqué dans un commentaire précédent, on mettra sans doute à disposition deux méthodes afin de rester rétrocomptaible avec l'existant en terme de mots clefs velocity :
- 1 méthode qui renvoie les 4 premiers chiffres (avec le même nom qu'avant pour la rétrocomptaibilité)
- 1 méthode qui renvoie les 6 premiers chiffres (avec un nouveau nom)

Par contre, ce ne sera malheureusement pas rétroactif : les infos n'ont jamais été sotckés et masqués mais réellement filtrées.
Commentaire de Cedric Favero [ 03/févr./09 12:09 ]
>Par contre, ce ne sera malheureusement pas rétroactif : les infos n'ont jamais été sotckés et masqués mais réellement filtrées.

Ok c'était le sens de ma question.
Dommage.

Ok pour les mots clés mais pourquoi une rétrocompatibilité? Les mots-clés ne s'appliquent que sur les nouveaux paniers...
M'enfin mieux vaut trop que pas assez.
Commentaire de Fabien Bourdoulous [ 05/févr./09 10:02 ]
Il y a maintenant 6 mots clefs velocity pour prendre en compte les 5e et 6e chiffres :
carte exotique - 0000/4505 > 80 euros
carte exotique - 4507/5134 > 80 euros
carte exotique - 5139/9999 > 80 euros
carte exotique - 000000/450599 > 80 euros
carte exotique - 450700/513499 > 80 euros
carte exotique - 513900/999999 > 80 euros
Commentaire de Cedric Favero [ 05/févr./09 10:03 ]
Tu les as modifiés directement? En prod?
En général c'est moi qui gère les mots clés.
Commentaire de Fabien Bourdoulous [ 05/févr./09 10:10 ]
En fait il s'agit des exemples réalisés en dev.
Commentaire de Fabien Bourdoulous [ 05/févr./09 10:56 ]
OK, c'est mis en place.
Dans les objets "PurchaseFormat.java" utilisés dans les contextes Velocity, en particulier pour les mots clefs (de type Confirmation Panier), 2 changements :

$purchase.CardNumberBegin ==> pour la rétrocompatibilité, renvoie toujours seulement les 4 premiers chiffres de la CB
$purchase.CardNumberBegin6 ==> renvoie les 6 premiers chiffres de la CB

Pareil pour les méthodes qui renvoient les valeurs (pour les test numériques)
$purchase.CardNumberBeginValue
$purchase.CardNumberBeginValue6

Pour info :
1 script dans le répertoire TX-E : VTX-E_APP_15131_ALL_01_purchase_modify_col.sql

1 commit :
revno: 24757
committer: fabien.bourdoulous <fabien.bourdoulous@priceminister.com>
branch nick: tx
timestamp: Wed 2009-02-04 18:59:38 +0100
message:
  APP-15131 [TX-E] [CoSAV] Conservation des 6 premiers chiffres de la cb
modified:
  source/etc/jdbc.properties
  source/etc/priceminister-infra.properties
  source/generated/build/generate.properties
  source/src/com/babelstore/purchase/PurchaseFormat.java
  source/src/com/babelstore/purchase/PurchaseInfo.java
  source/src/com/babelstore/purchase/business/PurchaseBusinessBean.java
Commentaire de Cedric Favero [ 05/févr./09 17:20 ]
Ok donc les mots clés sont "doublés".?
Est-il nécessaire de garder les anciens si tous les nouveaux paniers font figurer les 6 chiffres?
Commentaire de Arnaud Forgues [ 05/févr./09 18:01 ]
Pour faire le test en DEV, on a en effet doublés les mot clés. Mais c'est toi qui vois ce que tu veux faire. A terme on peut en effet imaginer qu'on n'aura plus besoin de la méthode "$purchase.CardNumberBegin" (avec uniquement 4 chiffres)

En gros, c'est principalement pour gérer la période de transition que l'on a mis à disposition les 2 méthodes, le temps que tu migres tu les mots clefs qui utilise cette méthode.
Commentaire de Cedric Favero [ 05/févr./09 18:06 ]
Ok parfait. Merci.
Commentaire de Sebastien Bruzzone [ 13/févr./09 15:27 ]
ok c'est bon pour moi, tout semble marcher




Migration du mécanisme d'import des fichiers de Phaeton vers Bacchus (EXP-2759)

[EXP-2760] Test et validation du bon fonctionnement du service sur Bacchus Création: 29/sept./06 13:42  Mise à jour: 25/juin/07 18:59  Résolue: 21/nov./06 18:03

Etat: Résolu
Projet: Exploitation
Composants: Evolution
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Patrice Boulanger Attribution: Eric Vannier
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: XML File Config_import1_es.xml     Zip Archive tests.zip    
Pays:
ALL - Tous

 Description   
Merci de noter ici l'ensemble des tests qui ont été et qui seront réalisés afin de valider le bon fonctionnement du nouveau ftpSwitch sur Bacchus.

 Commentaires   
Commentaire de Eric Vannier [ 02/oct./06 10:31 ]
Les différents tests pour valider le fonctionnement de ftpSwitch :

1°) On post 4 fichiers sur un compte ftp au format compressé gz , tar.gz, Zip et non compressé
2°) On crée un fichier de Config pour que les fichier soient décompressés (Filtre Expand)
3°) On déplace les fichiers vers un autre répertoire (Filtre Move)
4°) On fait une comparaison entre deux fichiers avec une différence d'une ligne par ex. (Filtre Diif)
5°) On crée un fichier qui extrait deux trois champs d'un fichier source pour le mettre dans un autre (Filtre ExtraitData)
6°) On crée un fichier à partir de quelques champs d'un fichier source (FileFromData)
Commentaire de Daniel Pintamalli [ 04/oct./06 11:13 ]
Tests en cours.
Commentaire de Daniel Pintamalli [ 04/oct./06 18:47 ]
Test OK.

En PJ les résultats correspondant à chaque test.
Commentaire de Eric Vannier [ 06/oct./06 17:13 ]
On a validé le fonctionnement de ftpSwitch et de ses divers filtres
Commentaire de Eric Vannier [ 06/oct./06 17:16 ]
On doit encore valider malgré que ce sont ceux qui tournent sur Hercule :

le seul changement ce sont des variables d'environnements (base, serveur, login, pays)
ftpCompute_ng.sh
import_ng_sh

import_images.pl
Commentaire de Eric Vannier [ 06/oct./06 17:17 ]
Actuellement, on est bloqué par des clés ssh dans le sens Esculape vers Bacchus , ça fonctionne dans l'autre sens.
Commentaire de Eric Vannier [ 09/oct./06 14:48 ]
Le problème de clés ssh a été résolu, maintenant on attend la résolution du soucis de modules perl pour oracle 10.

La synchronisation des comptes ftp sur Bacchus et Phaeton et des répertoires pmftpstock a été effectué.
Commentaire de Eric Vannier [ 11/oct./06 18:51 ]
Le soucis des modules perl sur esculape a été résolu.
ftpCompute_ng.pl a déplacé les fichiers des divers tests précédents.

import_ng.sh ne fonctionne pas car , il faut initialiser les "jndi.properties" d'après le jira EXP-2640 qui a le même soucis.

Quelqu'un pourrait m'aider sur ce pb ?
Commentaire de Patrice Boulanger [ 12/oct./06 09:58 ]
Judd,

Peux tu nous renseigner là dessus?
Commentaire de Eric Vannier [ 12/oct./06 10:31 ]
[pmas@esculape advert_import_script]$ ./import_ng.sh -d --env PROD_ES
On lance importe avec les paramètres suivants : --mode FTP
     --in ../advert_import_readyforprocessing
     --filename 10802793_stock_4028937_priceminister-vivos.txt.pm
     --out /data/priceminister/upload/es/advert_import_work/2006-10-12_10-28-52
     --sqlloader /appli/oracle/product/10.2.0/db_1/bin/sqlldr
     --sqlconnect babel_1/babel_1@OLTPES
     --java /appli/priceminister/jdk/bin/java
     --cp /data/priceminister/batch:/data/priceminister/client/pm-main-client.jar:/data/priceminister/client/pm-batch.jar:/appli/priceminister/jboss/client/avalon-framework.jar:/appli/priceminister/jboss/client/jbosscx-client.jar:/appli/priceminister/jboss/client/commons-logging.jar:/appli/priceminister/jboss/client/log4j.jar:/appli/priceminister/jboss/client/jmx-client.jar:/appli/priceminister/jboss/client/jboss-aspect-library-jdk50.jar:/appli/priceminister/jboss/client/jnp-client.jar:/appli/priceminister/jboss/client/scout.jar:/appli/priceminister/jboss/client/jboss-ws4ee-client.jar:/appli/priceminister/jboss/client/hibernate-annotations.jar:/appli/priceminister/jboss/client/jboss-deployment.jar:/appli/priceminister/jboss/client/jboss-transaction-client.jar:/appli/priceminister/jboss/client/jbossjmx-ant.jar:/appli/priceminister/jboss/client/jbossall-client.jar:/appli/priceminister/jboss/client/ejb3-persistence.jar:/appli/priceminister/jboss/client/activation.jar:/appli/priceminister/jboss/client/jacorb.jar:/appli/priceminister/jboss/client/concurrent.jar:/appli/priceminister/jboss/client/jboss-common-client.jar:/appli/priceminister/jboss/client/jboss-jaxrpc.jar:/appli/priceminister/jboss/client/hibernate3.jar:/appli/priceminister/jboss/client/logkit.jar:/appli/priceminister/jboss/client/cglib-2.1.jar:/appli/priceminister/jboss/client/velocity-dep-1.4.jar:/appli/priceminister/jboss/client/mail.jar:/appli/priceminister/jboss/client/jbossha-client.jar:/appli/priceminister/jboss/client/jboss-aop-jdk50.jar:/appli/priceminister/jboss/client/jboss-ejb3.jar:/appli/priceminister/jboss/client/jboss-saaj.jar:/appli/priceminister/jboss/client/namespace.jar:/appli/priceminister/jboss/client/jboss-juddiaxis.jar:/appli/priceminister/jboss/client/commons-discovery.jar:/appli/priceminister/jboss/client/jboss-iiop-client.jar:/appli/priceminister/jboss/client/getopt.jar:/appli/priceminister/jboss/client/jbosssx-client.jar:/appli/priceminister/jboss/client/jmx-invoker-adaptor-client.jar:/appli/priceminister/jboss/client/wsdl4j.jar:/appli/priceminister/jboss/client/jboss-system-client.jar:/appli/priceminister/jboss/client/jbossmq-client.jar:/appli/priceminister/jboss/client/jboss-client.jar:/appli/priceminister/jboss/client/asm.jar:/appli/priceminister/jboss/client/jboss-j2ee.jar:/appli/priceminister/jboss/client/jboss-jsr77-client.jar:/appli/priceminister/jboss/client/axis-ws4ee.jar --userid 10802793
                         --profileid 4028937
                         --originalfile priceminister-vivos.txt.pm
./import.pl --mode FTP
     --in ../advert_import_readyforprocessing
     --filename 10802793_stock_4028937_priceminister-vivos.txt.pm
     --out /data/priceminister/upload/es/advert_import_work/2006-10-12_10-28-52
     --sqlloader /appli/oracle/product/10.2.0/db_1/bin/sqlldr
     --sqlconnect babel_1/babel_1@OLTPES
     --java /appli/priceminister/jdk/bin/java
     --cp /data/priceminister/batch:/data/priceminister/client/pm-main-client.jar:/data/priceminister/client/pm-batch.jar:/appli/priceminister/jboss/client/avalon-framework.jar:/appli/priceminister/jboss/client/jbosscx-client.jar:/appli/priceminister/jboss/client/commons-logging.jar:/appli/priceminister/jboss/client/log4j.jar:/appli/priceminister/jboss/client/jmx-client.jar:/appli/priceminister/jboss/client/jboss-aspect-library-jdk50.jar:/appli/priceminister/jboss/client/jnp-client.jar:/appli/priceminister/jboss/client/scout.jar:/appli/priceminister/jboss/client/jboss-ws4ee-client.jar:/appli/priceminister/jboss/client/hibernate-annotations.jar:/appli/priceminister/jboss/client/jboss-deployment.jar:/appli/priceminister/jboss/client/jboss-transaction-client.jar:/appli/priceminister/jboss/client/jbossjmx-ant.jar:/appli/priceminister/jboss/client/jbossall-client.jar:/appli/priceminister/jboss/client/ejb3-persistence.jar:/appli/priceminister/jboss/client/activation.jar:/appli/priceminister/jboss/client/jacorb.jar:/appli/priceminister/jboss/client/concurrent.jar:/appli/priceminister/jboss/client/jboss-common-client.jar:/appli/priceminister/jboss/client/jboss-jaxrpc.jar:/appli/priceminister/jboss/client/hibernate3.jar:/appli/priceminister/jboss/client/logkit.jar:/appli/priceminister/jboss/client/cglib-2.1.jar:/appli/priceminister/jboss/client/velocity-dep-1.4.jar:/appli/priceminister/jboss/client/mail.jar:/appli/priceminister/jboss/client/jbossha-client.jar:/appli/priceminister/jboss/client/jboss-aop-jdk50.jar:/appli/priceminister/jboss/client/jboss-ejb3.jar:/appli/priceminister/jboss/client/jboss-saaj.jar:/appli/priceminister/jboss/client/namespace.jar:/appli/priceminister/jboss/client/jboss-juddiaxis.jar:/appli/priceminister/jboss/client/commons-discovery.jar:/appli/priceminister/jboss/client/jboss-iiop-client.jar:/appli/priceminister/jboss/client/getopt.jar:/appli/priceminister/jboss/client/jbosssx-client.jar:/appli/priceminister/jboss/client/jmx-invoker-adaptor-client.jar:/appli/priceminister/jboss/client/wsdl4j.jar:/appli/priceminister/jboss/client/jboss-system-client.jar:/appli/priceminister/jboss/client/jbossmq-client.jar:/appli/priceminister/jboss/client/jboss-client.jar:/appli/priceminister/jboss/client/asm.jar:/appli/priceminister/jboss/client/jboss-j2ee.jar:/appli/priceminister/jboss/client/jboss-jsr77-client.jar:/appli/priceminister/jboss/client/axis-ws4ee.jar --userid 10802793
                         --profileid 4028937
                         --originalfile priceminister-vivos.txt.pm
Tous les fichiers n'ont pas été traités, veuillez consulter le fichier log/ftp.lst.exp.bad pour corriger le soucis puis relancer le script.
[pmas@esculape advert_import_script]$
Commentaire de Judd OSullivan [ 12/oct./06 14:53 ]
Copie un jndi.properties dans le répertoire /data/priceminister/batch. Prend l'exemple qui se trouve sur hercule.
Commentaire de Eric Vannier [ 12/oct./06 15:20 ]
J'ai copié le jndi.properties, batch.properties et jdbc.properties.

J'ai conservé car déjà présent le batchlist sur esculape.

j'ai mis ces trois fichiers dans "/data/priceminister/batch".

qd je lance , j'ai l'erreur suivante :

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
        java.rmi.ServerException: EJBException:; nested exception is:
        javax.ejb.EJBException: null; CausedByException is:
        null; CausedByException is:
        No such entity!; nested exception is:
        javax.ejb.EJBException: null; CausedByException is:
        No such entity!
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:325)
        at sun.rmi.transport.Transport$1.run(Transport.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
        at java.lang.Thread.run(Thread.java:595)
        at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
        at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
        at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
        at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:118)
        at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
        at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167)
        at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
        at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
        at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:169)
        at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
        at $Proxy0.create(Unknown Source)
        at com.babelstore.datafile.client.DataFileClient.main(DataFileClient.java:90)
Caused by: java.rmi.ServerException: EJBException:; nested exception is:
        javax.ejb.EJBException: null; CausedByException is:
        null; CausedByException is:
        No such entity!; nested exception is:
        javax.ejb.EJBException: null; CausedByException is:
        No such entity!
        at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:352)
        at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:125)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93)
        at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:508)
        at org.jboss.ejb.Container.invoke(Container.java:894)
        at sun.reflect.GeneratedMethodAccessor148.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805)
        at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
        at sun.rmi.transport.Transport$1.run(Transport.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
        at java.lang.Thread.run(Thread.java:595)
Caused by: javax.ejb.EJBException: null; CausedByException is:
        null; CausedByException is:
        No such entity!; nested exception is:
        javax.ejb.EJBException: null; CausedByException is:
        No such entity!
        at com.babelstore.datafile.business.DataFileBusinessBean.ejbCreate(DataFileBusinessBean.java:63)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity(CMPPersistenceManager.java:181)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createEntity(CachedConnectionInterceptor.java:266)
        at org.jboss.ejb.EntityContainer.createHome(EntityContainer.java:766)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
        at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1113)
        at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:90)
        at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:192)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:212)
        at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:90)
        at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:117)
        at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:61)
        at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:28)
        at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:41)
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:109)
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:335)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:146)
        at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:116)
        at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:121)
        ... 24 more
L'import a échoué, on déplace le fichier [10802793_stock_4028937_priceminister-vivos.txt.pm] dans le répertoire d'origine pour qu'il soit à nouveau traité
Commentaire de Eric Vannier [ 16/oct./06 09:58 ]
Peux-tu me résumer ce que tu as fait Vendredi car ça a résolu le pb ?
Merci
Commentaire de Judd OSullivan [ 16/oct./06 10:59 ]
Apparement le client voulait un log4j.xml que j'ai copié dans ~/batch/. Ca serait bien de mettre la même version de ce fichier qu'il y a sur hercule (j'ai copié une version d'ailleurs).

Le plantage avec l'entity not found n'est pas très utile malheureusement. A voir si on peut faire mieux.
Commentaire de Eric Vannier [ 16/oct./06 11:42 ]
Bacchus et esculape sont prêt pour subir une batterie de test avant l'import réel.
Commentaire de Eric Vannier [ 14/nov./06 12:10 ]
Le basculement a été réalisé hier dans la journée via la modification des serveurs dn pour ftp.priceminister.com.

Maintenant, il suffit d'observer si aucun problème survient au niveau des imports, du bi et des commerciaux.
Commentaire de Eric Vannier [ 21/nov./06 18:03 ]
Je clôture cette demande car j'ai plus aucun partenaire qui arrive sur Phaeton.

Le BI ont migré le seul script qui utilisait le ftp pour utiliser celui de bacchus.

J'ai migré et validé les comptes ftp des commerciaux (newsletter, adoc, popup, affiliation et visuels)




[BIN-232] [Routage] : envoi one shot du mail PMV crédité non activé début décembre Création: 28/nov./06 16:27  Mise à jour: 26/nov./07 13:25  Echéance: 08/déc./06 00:00  Résolue: 26/nov./07 13:25

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures

Liens des demandes:
Dépendance
bloque BIN-245 [Etude PMV] : nb de paniers et VA gén... Fermé
Similaire
similaire à DEC-307 [PMV crédités mais non activés] Extra... Fermé
Pays:
FRA - France

 Description   
Salut agathe,

nous souhaitons refaire un envoi du mailing PMV crédité non activé sur la 1ère semaine de décembre.
Les critères de l'extraction sont les mêmes que ceux que nous avions utilisés pour l'envoi en 1 shot de mai dernier avec une condition supplémentaire qui est : Exclure ceux qui avaient un PMV crédité non activé avant le 22/05/2006.

Penses-tu pouvoir me fournir un fichier des détenteurs de PMV crédité non activés depuis le 22/05/2006 avec :
leur adresse-email
leur pseudo
le solde disponible sur leur PMV
la date de crédit de leur PMV

Nous ferons cet envoi sur le compte secondaire d'EMV avant la fin de la semaine prochaine. Penses-tu pouvoir être dans les temps ? Je sais que je te préviens un peu tard mais nous n'avons pas d'autre choix que de faire l'envoi au moins 3 semaines avant qu'on nous coupe nos accès sur EMV...

 Commentaires   
Commentaire de Agathe Remy [ 28/nov./06 18:07 ]
Mohamed,

Peux-tu voir avec Alex comment faire son extraction dans BI?

Merci:-)
Agathe
Commentaire de Mohamed Ezzouak [ 04/déc./06 18:40 ]
Nous avons fait avec Alexandra un rapport qui liste les pseudo/email qui ont un solde PMV positif et qui n'ont pas activé leur PMV depuis Juin 2006.
Nous n'avons pas pu poser de conditions pour ne prendre que les PMV non activé depuis le 22/05/2006 car nous n'avons pas d'objets avec le jour.
Nous avons donc pris l'objet sur le mois qui nous a permis de filtrer les PMV non activés depuis Juin 2006.

Il y a donc 8 jours qui ne sont pas analysés.


Commentaire de Agathe Remy [ 11/déc./06 13:46 ]
Alex,

Peux-tu me donner le nom du rapport que vous avez fait avec Mohamed pour traiter cette problématique?

Merci:-)
Agathe
Commentaire de Alexandra Viravaud [ 11/déc./06 14:38 ]
On ne l'a pas enregitré car c'était pendant la période précédent le passage à la nouvelle version BI.
Au mieux, je peux te faire suivre le tableau excel de l'extract.
Commentaire de Agathe Remy [ 11/déc./06 16:05 ]
Alex,

J'aimerais que tu essaies de recréer le rapport dans Mes Favoris tant que c'est encore frais parce que je pense que nous en aurons encore besoin.
Peux-tu le faire cette semaine afin que je le valide?

Je reste à ta disposition si tu as des questions et n'hésite pas à nous contacter si tu as besoin d'aide!

Agathe




Nettoyage : retirer tout le code hitbox/websitestory (APP-11697)

[APP-14414] Supprimer les colonnes superflues dans la base Création: 21/déc./06 18:25  Mise à jour: 13/janv./09 11:53  Résolue: 07/janv./09 15:54

Etat: Fermé
Projet: Application PriceMinister
Composants: XITI
Affecte la/les version(s): 12.0.0
Version(s) corrigée(s): 38.0.0 (TX-D Bis)

Type: Sous-tâche Priorité: Majeur
Rapporteur: Alexandre Garnier Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM: *** A PLANIFIER ***
Classif1: IG
Classif2: IG - xiti
Projets PM archivés: Maintenance CTN-B

 Description   
Pour le moment, afin de gérer les branches CVS, les colonnes HitBox on juste été dupliquées.
Lorsque cela sera bon pour tout le monde, il faudra les supprimer et adapter les Business associés.
ADMINISTRATION -> BRAND -> STATISTICS_HITBOX_1/2
USER -> UST_GROUP -> STATISTICS_HITBOX_1/2

 Commentaires   
Commentaire de Alexandre Garnier [ 14/sept./07 12:32 ]
Attention à vérifier que le BI utilise bien les nouvelles colonnes.
Commentaire de Alexandre Garnier [ 28/sept./07 12:05 ]
1ère étape faite : génération des generated avec exclusion de ces colonnes.
Au niveau BI, c'est bon sur le passage vers brand.statistics_xiti et ust_group.statistics_1/2 ?
Je crains que pour brand, l'info ai été oublié dans le wiki : disparition des colonnes statistics_hitbox1/2 (déjà nulles pour les nouveau co branding, mais p-e à conserver au niveau BI) au profit de la colonne statistics_xiti
Commentaire de Alexandre Garnier [ 02/janv./08 11:44 ]
Attendre la fin de la branche NPF9
Commentaire de Alexandre Garnier [ 16/sept./08 17:33 ]
On vient de se retrouver avec ces colonnes en DEV. Elles existent encore en INTEG aussi. A voir en PROD.
Le script se trouve dans : V:\Database\old\V21\V21_0_0\prod\04_POST_DEPLOY\V20_0_0_ALL_APP-14414_drop_hitbox_columns.sql

Il vient d'être repassé en DEV.

garniera@boulard:/home/Groups/technique/Database 17:17:03 $ find . -name *APP-14414*
./old/V20/V20_0_0/dev/log/V20_0_0_ALL_APP-14414_drop_hitbox_columns.sql_DEV5.log
./old/V20/V20_0_0/dev/log/V20_0_0_ALL_APP-14414_drop_hitbox_columns.sql_DEV_ESP.log
./old/V18/V18_0_0/dev/log/V18_0_0_ALL_APP-14414_drop_hitbox_columns.sql_DEV5.log
./old/V18/V18_0_0/dev/log/V18_0_0_ALL_APP-14414_drop_hitbox_columns.sql_DEV_ESP.log
./old/V21/V21_0_0/prod/04_POST_DEPLOY/V20_0_0_ALL_APP-14414_drop_hitbox_columns.sql
./old/V21/V21_0_0/integ/04_POST_DEPLOY/log/V20_0_0_ALL_APP-14414_drop_hitbox_columns.sql_INTEG_FRA.log
./old/V21/V21_0_0/integ/04_POST_DEPLOY/log/V20_0_0_ALL_APP-14414_drop_hitbox_columns.sql_INTEG_ESP.log
./old/V21/V21_0_0/integ/04_POST_DEPLOY/log/V20_0_0_ALL_APP-14414_drop_hitbox_columns.sql_INTEG_UK.log
./CTN_G/dev/log/CTN_G_ALL_APP-14414_drop_hitbox_columns.sql_DEV6.log
./CTN_G/dev/log/CTN_G_ALL_APP-14414_drop_hitbox_columns.sql_DEV_ESP.log
./CTN_G/dev/log/CTN_G_ALL_APP-14414_drop_hitbox_columns.sql_DEV_UK.log
Commentaire de Patrick Pereira [ 07/janv./09 15:54 ]
C'est fait.




[EXP-3498] Ajouter les adresses locales des serveurs web dans le fichier nonblock.list Création: 17/avr./07 16:23  Mise à jour: 25/juin/07 19:00  Résolue: 03/mai/07 09:47

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Critique
Rapporteur: Patrice Boulanger Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Dans les logs des serveurs Web, on trouve:

[Tue Apr 17 01:57:53 2007] [error] [client 212.23.167.8] client denied by server configuration: root_games
[Tue Apr 17 01:57:53 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html
[Tue Apr 17 01:57:54 2007] [error] [client 212.23.167.8] client denied by server configuration: Tel-PDA
[Tue Apr 17 01:57:54 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html
[Tue Apr 17 01:57:55 2007] [error] [client 212.23.167.8] client denied by server configuration: tab_600
[Tue Apr 17 01:57:55 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html
[Tue Apr 17 01:57:56 2007] [error] [client 212.23.167.8] client denied by server configuration: tab_700
[Tue Apr 17 01:57:56 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html
[Tue Apr 17 01:57:57 2007] [error] [client 212.23.167.8] client denied by server configuration: bargain
[Tue Apr 17 01:57:57 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html
[Tue Apr 17 01:57:58 2007] [error] [client 212.23.167.8] client denied by server configuration: root_white
[Tue Apr 17 01:57:58 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html
[Tue Apr 17 01:57:59 2007] [error] [client 212.23.167.8] client denied by server configuration: root_baby
[Tue Apr 17 01:57:59 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html
[Tue Apr 17 01:58:00 2007] [error] [client 212.23.167.8] client denied by server configuration: root_clothing
[Tue Apr 17 01:58:00 2007] [error] [client 212.23.167.8] client denied by server configuration: 403.html

Il semblerait donc que minitor s'amuse à bloquer le serveur web lui-même lors de la génération des pages statiques.

Comme c'est assez ennuyeux, je propose d'ajouter les adresses locales des serveurs dans le fichier nonblock.list.



 Commentaires   
Commentaire de Jérémie Bennejean [ 17/avr./07 16:48 ]
J'ai rajouté dans le nonblock.list de
PHAETON
#ADRESSES PHAETON
212.23.167.28
212.23.167.24
212.23.167.21
212.23.167.22
212.23.167.4
212.23.167.5
212.23.167.6
212.23.167.7
212.23.167.8
212.23.167.9
212.23.167.10
212.23.167.11
212.23.167.12
212.23.167.13
212.23.167.14
212.23.167.15
212.23.167.16
212.23.167.20
212.23.167.23
212.23.167.25

CUPIDON
#ADRESSES CUPIDON
212.23.167.30
212.23.167.31
212.23.167.32
212.23.167.33
212.23.167.34
212.23.167.35
212.23.167.36
212.23.167.37
212.23.167.38
212.23.167.39
212.23.167.43
212.23.167.44
212.23.167.45
212.23.167.46
212.23.167.47
212.23.167.48

ARICIA
212.23.170.247

Les adresses suivantes existaient deja dans le nonblock.list de aricia
212.23.170.244
212.23.170.241
212.23.170.248
212.23.170.243
212.23.170.242
212.23.170.251
212.23.170.249
212.23.170.252
212.23.170.253
212.23.170.240
212.23.170.246
212.23.170.250
212.23.170.245
212.23.170.254

Sur chaque serveur web j'ai fais un configtest et un graceful
Commentaire de Jérémie Bennejean [ 19/avr./07 15:49 ]
Malgré l'ajout des adresses dans le fichiers de chacun des serveurs webs, il y a toujours ces erreurs dans les logs
Commentaire de Jérémie Bennejean [ 30/avr./07 11:18 ]
[mrtg@phaeton mrtg]$ grep -ir nonblock.list *
minitord/bin/apache_block_ip.pl:my $white_list = "/data/chrootapache/usr/local/apache/conf/nonblock.list";
Commentaire de Jérémie Bennejean [ 30/avr./07 11:20 ]
Sur aricia l'@ (212.23.170.248) en deny correspond au vh-intra
Sur phaeton l'@ (212.23.170.8) en deny correspond au vh-eglue, vh-bo,vi-intra,vh-bi
Sur cupuidon l'@ (212.23.170.33) en deny correspond au vh-eglue, vh-bo,vi-intra,vh-bi
Commentaire de Jérémie Bennejean [ 30/avr./07 14:10 ]
Pour résoudre l'apparition de certaines erreurs dans le error_log, j'ai ajouté dans la conf apache de cupidon (dans 1 er temps et faire le test) au sein des vh eglue et bi dans la Allow from 212.23.170.33
Commentaire de Jérémie Bennejean [ 30/avr./07 14:56 ]
Pour faire face à cette erreur qui revient tres souvent j'ai fais un touch du fichier demandé. J'ouvre aussi un jira à l'équipe de swan.
[Mon Apr 30 13:52:26 2007] [error] [client 195.12.230.196] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif---> OK touch a_arrowb2.gif
Commentaire de Jérémie Bennejean [ 30/avr./07 14:58 ]
idem [Mon Apr 30 14:54:15 2007] [error] [client 82.228.143.55] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-www/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif, referer: https://www.priceminister.com/connect?action=login&dest=%2Fpurchase%3Faction%3Dsalelist%26login%3Dmargo1230_3&login=margo1230_3
Commentaire de Jérémie Bennejean [ 30/avr./07 15:01 ]
sur phaeton:

[Mon Apr 30 13:42:36 2007] [error] [client 195.12.230.202] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif, referer: http://www.priceminister.com/navigation/search/category/search_books/keyword/singer-christiane/ss/70

[Mon Apr 30 14:36:34 2007] [error] [client 82.241.240.95] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-www/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif, referer: https://www.priceminister.com/connect?action=login&c=81&dest=%2Fcheckout%3Faction%3Daddress
Commentaire de Jérémie Bennejean [ 30/avr./07 15:05 ]
sur aricia :

[Mon Apr 30 14:54:15 2007] [error] [client 82.228.143.55] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-www/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif, referer: https://www.priceminister.com/connect?action=login&dest=%2Fpurchase%3Faction%3Dsalelist%26login%3Dmargo1230_3&login=margo1230_3

[Mon Apr 30 12:43:11 2007] [error] [client 86.201.188.113] File does not exist: /usr/local/apache/htdocs/pmweb/virtualhost-camif/content/V14_0_1/front/brand/www/images/default/bullet/a_arrowb2.gif, referer: https://occasion.camif.fr/connect?action=login&c=81&dest=%2Fcheckout%3Faction%3Daddress




[BIN-343] [Finance] : Détail des sommes à rembourser aux acheteurs Création: 26/juin/07 15:14  Mise à jour: 18/mars/10 12:33

Etat: Ré-ouvert
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Philippe Favrot Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word DMR - buyer refund v2.0.doc    
Pays:
ALL - Tous

 Description   
Bonjour,
Nous poursuivons nos travaux de "mise au carré" de la comptabilisation des claims (ZVRA / PVRA / PVZA) par la partie remboursements aux acheteurs.
Nous avons d'un côté les montants à rembourser aux acheteurs (reportés dans le rapport "claims status") :
      - buyer bonus (PVRA / ZVRA)
      - buyer payment (ZVRA)
et de l'autre les sommes réellement remboursées aux acheteurs par crédit sur leur PMV (type : credit_BO ; cause : remboursement).
Nous avons besoin d'avoir à la fin de chaque mois la liste des sommes (pseudos / numéro de panier / date d'autorisation / montant ...) restant dues aux acheteurs (ie somme en attente de crédit sur les PMV).
Nous restons, Claudie et moi, à votre disposition pour préciser cette demande.
Merci
Philippe

 Commentaires   
Commentaire de Romain Czornomaz [ 28/août/07 12:06 ]
Philippe,

Après investigation avec les équipes dev, il n'est pas possible en l'etat de fournir un rapport avec les numeros de paniers , dates d'autorisation, montants à rembourser aux acheteurs en attente.
En effet pour cela, nous devons nous baser sur les operations PMV et il n'existe pas actuellement de lien entre les operations et les items ou paniers.

Je te propose que nous attendions le retour d' Agathe la semaine prochaine pour en discuter avec elle et essayer de trouver une solution.

Merci de ta compréhension,

Romain
Commentaire de Agathe Remy [ 18/févr./08 11:24 ]
Nouveau rapport sur les remboursements acheteurs en attente de paiement sur le PMV (~400 000 euros).
Ce rapport risque de nécessiter la mise en relation entre les opérations et les transactions qui aujourd'hui n'existe que dans un champ « description ».

A spécifier...
Commentaire de Agathe Remy [ 25/juil./08 20:39 ]
Philippe,

Ce JIRA est-il toujours d'actualité ?

Agathe
Commentaire de Dalila Belkebir [ 19/août/08 14:44 ]
Bonjour Claudie,

Tu trouveras disponible en production (FR & ES) les changements suivants :

- Prise en compte de l'Item Buyer Bonus dans le calcul du Total Refund Amount pour les claims ZVRA dans les rapports :
      « buyer debt summary »
      « buyer debt by claim closing month »
      « buyer refund operation » (déjà pris en compte auparavant)

- Mise en négatif du Total Refund Amount pour les Remboursement à tort (operation cause id = 80) dans le rapport :
      « buyer refund operation »
 
- Création d'un répertoire Histo_Financial afin de permettre de marginaliser le rapport (rapport toujours disponible mais non utilisé) :
« buyer debt »

Dalila.
Commentaire de Agathe Remy [ 15/sept./08 11:03 ]
Bonjour Claudie,

S'il te plait, peux-tu valider ces modifs?

Merci.
Agathe
Commentaire de Dalila Belkebir [ 15/oct./08 16:37 ]
Retour de Claudie sur le rapport Buyer refund operation :

1- ce rapport reprend l'ensemble des opérations qui ont été payées aux acheteurs.
Le total de la colonne « operation cause » doit pouvoir être rapproché des mouvements sur le PMV issus du rapport « BO operations by cause ».
Cf détail du rapprochement ci-dessous.
Il ressort un écart sur le total de la cause « remboursés à tort » et le total de la cause « remboursement »

2- Je pense que l'écart s'explique en partie, par les « anomalies » ci-dessous :
En effet, je ne comprends pas pourquoi les causes « paiement vente » et « payé à tort » apparaissent.
Ces causes concernent uniquement les vendeurs.

**** « Payé à tort », une seule opération, cf ci-dessous extrait du rapport
Je pense que cette ligne ne devrait tout simplement pas apparaitre (Le payé à tort concerne le vendeur « 19teca74 », on retrouve la transaction correspondante dans le seller credit)

**** « Paiement vente », trois opérations, cf ci-dessous, extrait du rapport :
Ces trois acheteurs, après consultation dans back office, ont bien été remboursés de 13.70, 30.80 et 78.30 euros.
Ce qui aurait du apparaitre dans le rapport c'est la cause « remboursement » et les montants suivants en « operation amount » de 13.70, 30.80, 78.30. Ces paiements vente concernent respectivement les vendeurs suivants : librosonline, stabiloxxpro , luzern-es
La claim aurait du être annulée mais elle a été maintenue suite blocage système, et les vendeurs ont donc fait l'objet d'un paiement vente pour qu'ils puissent être payés.


 


 
Commentaire de Agathe Remy [ 27/nov./08 11:19 ]
Bonjour Julien,

Peux-tu développer les rapports?
L'objectif est de livrer les rapports en France et en Espagne avant le 10/12/2008.
Merci!

Agathe
Commentaire de Agathe Remy [ 27/nov./08 11:21 ]
Voici les spécifications des rapports de rapprochement des remboursements acheteurs avec les transactions, validées par Claudie le 27/11/2008.

Elles sont également disponibles dans le répertoire :
V:\Reporting\BusinessIntelligence\En Développement\2008-10 Buyer debt

Agathe
Commentaire de Agathe Remy [ 17/févr./09 11:43 ]
Agathe,

Comme vu ensemble, voici ci-joint la synthèse de l'analyse des rapports « buyer refund... » sur l'Espagne.

Sur le premier onglet, j'ai donc ajouté une synthèse des écarts mis en évidence (en espérant qu'elle soit suffisamment claire) :
- Ecart sur le total des remboursements issus des rapports « buyer refund... » et « wallet operation by month »
- Ecart sur le total des colonnes des rapports "buyer refund..." onglet ZVRA et PVRA (total des transactions hors doublon)

N'hésite pas à revenir vers moi si tu as besoin d'explication ou précision sur cette synthèse

Merci à toi
claudie
Commentaire de Agathe Remy [ 17/févr./09 11:44 ]
Bonjour Claudie,
Je reviens vers toi sur les écarts dans les rapports « buyer refund »
Concernant l'écart sur le total des colonnes dans les onglets ZVRA et PVRA, nous avons identifié l'erreur et donc nous allons la corriger &#61514;
Pour l'écart sur le total des remboursements issus des rapports « buyer refund... » et « wallet operation by month » :
Le rapport "Buyer refund by claim closing month" se base sur la "claim closing date" de la transaction, alors que les rapports " Buyer refund without claim by completion month" et "Wallet operations by user" se base sur la completion date de l'opération.
Donc l'écart provient des opérations liées à une transaction dont la completion date est inférieur à 2009 mais dont la claim closing date est supérieur à 2009 et donc n'apparaissent pas dans les rapports.
Souhaites tu que les rapports évoluent pour prendre en compte ces transactions ?
N'hésite pas à nous solliciter pour plus d'informations.

Julien.
Commentaire de Julien Girardet [ 25/févr./09 16:41 ]
Bonjour Claudie,

les totaux des rapports "Buyer refund by claim closing month" et "Buyer refund without claim by completion month" sont corrigés.

Tu trouveras dans "Financial/Accounting" les versions corrigées de ces rapports en France, Spain et UK.


Julien.
Commentaire de Agathe Remy [ 17/août/09 15:38 ]
Bonjour Philippe,

S'il te plait, peux-tu valider cette demande afin que nous puissions la clôturer?

Merci.
Agathe
Commentaire de Agathe Remy [ 18/août/09 10:00 ]
le 23/03/2009 :
Bonjour Agathe,

Je voudrais commencer à exploiter les rapports « buyer refund » sur la France à partir des données à fin mars 2009,
1ère analyse sur les remboursements puis plus tard finaliser l'analyse sur les remboursés à tort quand les rapports seront dispo.

Nous avions édité les rapports à fin 2008 avant que les rapports ne soient définitifs. Il nous faut donc aujourd'hui rééditer ces rapports pour tout l'historique du 01/01/2001 au 31/03/2009.
Il s'agit donc d'une édition très très lourde parce que très longue et cela suppose aussi d'éditer pour nous les rapports en morcelant les périodes.

Tu m'avais évoqué il y a quelque temps la possibilité de lancer ces rapports en une seule fois via le BI. Peux-tu me dire si cela est possible ?
On pourrait alors imaginer l'édition des deux rapports (« buyer refund by claim closing month » et «buyer refund without any claim ») de la façon suivante :
- Du 01/01/2001 au 31/12/2006 à la date que vous voulez puisqu'il n'y a à priori plus de mouvement sur les claims datant de cette période
- Du 01/01/2007 au 31/12/2008 le jour où les opérations du mois sont stabilisées (ce rapport serait à lancer tous les mois)
- 2009 serait édité par nous

Peux-tu nous tenir info,
Merci à toi
claudie
Commentaire de Agathe Remy [ 18/août/09 10:00 ]
le 10/04/2009 :
Bonjour Claudie,

Tu trouveras l'historique des rapports « Buyer refund » dans le répertoire :
 T:\BI\00 - Projets\2009-04 Historique Buyer Refund
¿ Buyer refund by claim closing month
¿ Buyer refund without claim by completion month
 
L'historique a été généré le jour de la stabilisation des chiffres du mois de Mars, c'est-à-dire Mardi dernier (07/04/09)
Et donc la période est du 01/01/2001 au 07/04/2009

A ta disposition pour plus d'informations.

Julien.
Commentaire de Dalila Belkebir [ 30/sept./09 13:49 ]
Bonjour Philippe,

S'il te plait, peux-tu valider cette demande afin que nous puissions la clôturer?
Sinon nous communiquer ce qu'il reste à faire.

Merci.
Dalila.
Commentaire de philippe favrot [ 30/sept./09 17:23 ]
Dalila,
c'est à Claudie de nous dire si on peut clôturer ce Jira ; pour être honnête je ne sais pas précisément où nous en sommes de ce chantier.
J'avais en revanche, compris que nous le laissions de côté pendant le congés maternité d'Agathe.
Maintenant si vous avez du temps pour avancer dessus, c'est bienvenu ! A voir avec Claudie
Merci
Philippe
Commentaire de Claudie Dufresne [ 01/oct./09 18:20 ]
Dalila,

Ce Jira est toujours en cours.

Une première étape a été possible via les rapports "buyer debt".
Ces rapports permettent en effet de faire un premier travail d'analyse des remboursements effectués par type de claim notamment.
Travail effectué sur l'Espagne et UK. Pour la France, l'analyse de l'antériorité, beaucoup plus volumineuse et "évolutive", est en toujours en cours.

les rapports "buyer debt" sont un premier outil d'analyse de l'antériorité, mais d'autres rapports seront nécessaires.
1- rapports de type "buyer debt" ne prenant en compte que les variations du mois
2- rapport permettant de lister les sommes (pseudos / numéro de panier / date d'autorisation / montant ...) restant dues aux acheteurs (ie somme en attente de crédit sur les PMV).

A votre dispo si vous voulez qu'on fasse un point
merci
claudie





[APP-20603] BDD tél fixes --> flux Création: 22/mai/08 14:38  Mise à jour: 21/juil./08 18:37  Résolue: 18/juil./08 18:03

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 21.0.0
Version(s) corrigée(s): 26.0.0 (TX-B)

Type: Tâche Priorité: Critique
Rapporteur: Ghislain Gridel Attribution: Renaud Dierickx
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg     JPEG File Solution_flux_BDD_Tel_fixe.JPG    
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-20820 Traduction des labels IG Sous-tâche Fermé Nerea Prieto  
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***
Classif FONC: comarket

 Description   
Bonjour,

Nous commercialisons la BDD de tél fixe via notre partenaire scanclic et pour cela nous devons avoir l'accord des PriceMembers pour commercialiser leur n° de tél fixe. Nous souhaiterions donc rajouter un bouton radio opt-in "Par téléphone" en-dessous du bouton "SMS "sur la page d'inscription. Voir ci-joint.
Ce bouton servira à optiniser les nouveaux membres.
Il faut coordonner cela avec Agathe pour que l'info puisse être envoyée à PN DATA par la suite.

Merci.


 



 Commentaires   
Commentaire de Ghislain Gridel [ 26/mai/08 11:53 ]
Bonjour,
cette demande est assez urgente. Savez-vous quand le bouton radio pourra être en ligne ?
Commentaire de Emeric Teil [ 04/juin/08 12:37 ]
Comme vu ensemble, on prend cette demande pour notre prochaine version. Celle-ci sortira soit fin juillet, soit fin aout...
Commentaire de Emeric Teil [ 04/juil./08 17:35 ]
OK en Dev
Commentaire de Ghislain Gridel [ 08/juil./08 11:40 ]
Recette ok. Merci.
Commentaire de Olga Costa [ 18/juil./08 14:57 ]
Il faut publier?
Commentaire de Ghislain Gridel [ 18/juil./08 16:07 ]
oui. Merci Olga.
Pourrais-je avoir le ien de désabonnement ?
Commentaire de Renaud Dierickx [ 18/juil./08 16:58 ]
Pour les urls de désabonnement, tout est sur les serveurs de recette en BO.
Marketing > Abonnements : liste > Voir screenshot-1

Les serveurs DEV TEST 6 et 7
==> /subscription?action=unsubscribe&email=prenom.nom%40domaine.fr&userid=123456&mailsubscriptionid=32
Commentaire de Ghislain Gridel [ 21/juil./08 10:47 ]
Merci Renaud,
donc dela donnera ça ?
www.priceminister.com/subscription?action=unsubscribe&email=prenom.nom%40domaine.fr&userid=123456&mailsubscriptionid=32
Dalila tu confirmes ?
Dalila, peux-tu compléter le JIRA avec les dates d'envoi des données à PN Data, stp ?
Merci !
Commentaire de Dalila Belkebir [ 21/juil./08 15:04 ]
Ghislain,

Désolée, mais je ne peux rien confirmer quant à l'URL que tu communiques.
Lors de notre précédent point, il était prévu que :
    - tu crées un JIRA dédié à l'équipe BI,
    - tu détermines avec l'aide de 1000mercis les critère de la cible pour l'envoi afin de déterminer si l'on doit la valider de notre côté,
    - les modifications du flux seront prises en compte lors de l'envoi mensuel du 02/09/2008 (attention, lors du flux 02/09/08 seules les données Optin fixe mises à jour (MAJ volontaires ou nouveaux inscrits) après envoi du mail seront remontées)

Pour ma part, je vais mettre à jour les spécifications et les développements du flux avec PN_DATA en fonction des informations que tu préciseras dans le nouveau JIRA.

Dalila.
97.48



Commentaire de Emeric Teil [ 21/juil./08 18:37 ]
OK en Integ. On ferme donc de notre côté. Merci, comme le suggère Dalila, de créer un Jira dédié au BI.




[BIN-335] Ecart entre Titan et BO Création: 23/mai/07 08:54  Mise à jour: 14/sept./07 18:04  Résolue: 28/mai/07 14:27

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Bloquant
Rapporteur: Philippe Favrot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel etude écarts panier coupon article avril 07.xls     Microsoft Excel exploit panier coupon article_avril 07.xls     Microsoft Excel Purchases_summary_by_month (avril 07).xls    
Pays:
FRA - France

 Description   
Bonjour,
écart entre Titan et BO au niveau du VA capturé pour avril :
Titan : 5 374 188
BO : 5 375 088
en pièce attachée :
- rapport Titan panier coupon article
- exploitation de ce rapport
- rapport purchase summary by month (B0).
Merci
Philippe

 Commentaires   
Commentaire de Philippe Favrot [ 23/mai/07 08:55 ]
pas possible de joindre le rapport Titan car plus de 10 Mo.
Je te le passe par amil.
Philippe
Commentaire de Agathe Remy [ 25/mai/07 17:33 ]
Philippe,

J'ai vérifié les données et elles sont identiques sur Titan et dans le DataWarehouse
En faisant la même requête sur Titan, j'obtiens bien 5 375 088 pour le montant capturé.

Maintenant, il s'agit de savoir pourquoi le rapport généré sur Titan ne donne pas les mêmes chiffres...

Agathe
Commentaire de Agathe Remy [ 25/mai/07 18:27 ]
Es-tu sur de ton traitement du fichier panier_coupons_articles? Parce que j'obtiens les mêmes chiffres sous BI et sur Titan...

Agathe
Commentaire de Agathe Remy [ 28/mai/07 14:27 ]
Philippe,

Dans le fichier ci-joint, tu trouveras le résultat de l'étude sur les écarts.
Il y a 900¿ d'écarts répartis sur le 24/04 (85¿) et le 29/04 (815¿).
Sur la journée du 29/04, j'ai comparé les résultats de ma requête sur titan (qui donne les mêmes résultats que le rapport BI) et celle d'un fichier panier_coupons_articles dans l'intranet.
Les données sont identiques.

La conclusion est donc :
- soit une erreur s'est produite lors de l'exploitation du fichier panier_coupons_articles dans Excel
- soit le fichier panier_coupons_articles exploité dans Excel était antérieur à la date de stabilisation des montants

Je clôture donc ce JIRA.

Agathe




[BIN-467] [Back-Office] : Ajout d'une dimension fabricant dans les univers Advert et Item Création: 27/juin/08 13:10  Mise à jour: 09/sept./08 10:53

Etat: Ouvert
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Pour pouvoir sortir des rapports pointus sur la contrefaçon , j'ai besoin de sortir des rapports aussi bien dans Advert que Item avec accès au champ ProductManufacturerName car je n'ai aujourd'hui accès qu'au titre de la fiche.

Il me faudrait donc dans ces 2 univers et dans le dossier Product une dimension ProductManufacturerName.

Merci d'avance.

 Commentaires   
Commentaire de Agathe Remy [ 07/juil./08 17:53 ]
Cédric,

Est-ce que la dimension que tu cherches n'est pas la suivante :
Product/Product Identification/Manufacturer Id
?
Elle est présente dans les univers ADVERT et ITEM.

merci de ton retour.

Agathe
Commentaire de Cedric Favero [ 07/juil./08 18:11 ]
Mais çà c'est le "code fabricant ", moi je voudrais pouvoir acceder au "nom fabricant" (ProductManufacturerName)

Pour pouvoir rechercher un terme dans ce dernier et pas obligatoirement spécifier un code particulier (surtout qu'ils peuvent maintenant etre générés à la volée lors de la création de fiche.)

Merci.
Commentaire de Agathe Remy [ 08/juil./08 10:37 ]
Bonjour Cédric,

Je ne vois pas trop ce que tu appelles le "ProductManufacturerName". Pourrais-tu me donner un exemple et me dire où tu trouves cette information?

Merci.

Agathe
Commentaire de Cedric Favero [ 08/juil./08 11:24 ]
Sur une fiche comme celle-ci:
http://bo.priceminister.com/referential_back?action=productview&productid=68190319

Le fabricant est Nike et le code fabricant est PM07081451 (valeur d'attribut)

Est-ce que dans la dimension Product/Product Identification/Manufacturer Id , je peux rechercher un terme comme "Nike" directement?

Merci.
Commentaire de Agathe Remy [ 08/juil./08 14:43 ]
Nous ne parlions donc absolument pas de la même chose.
L'objet "Manufacturer Id" donne l'identifiant fabricant et non le code de l'attribut fabricant.

Pour ta "valeur fabricant", il s'agit d'un attribut et nous ne récupérons pas encore les attributs dans BI en raison de l'instabilité due au chantier "Sauvons la Base Produit".
Mais en cherchant bien, je me suis aperçue qu'il existe une dénormalisation de cet attribut qui permettrait d'en récupérer la valeur directement à partir du produit. Nous devrions donc pouvoir te mettre à disposition cette information, moyennant un peu de développement.

Agathe

Commentaire de Cedric Favero [ 08/juil./08 15:37 ]
ah zut , c'est bien l'attribut fabricant dont j'ai besoin..
Il possible de le récuperer par le summary ou ce n'est pas dans BI non plus?

En fait j'ai besoin de faire des rapport sur des vendeurs avec un nb d'annonces ou de ventes pour telle ou telle marque dans le titre ou le champ fabricant.

Commentaire de Julien Girardet [ 08/juil./08 17:35 ]
Agathe,

J'ai ajouté dans l'univers Advert et Item la dimension "Product manufacturer name" dans la classe "Product" :
Ajout de la table DWH.TD_PRD_ATTRIBUTE_VALUE
 + jointure : DWH.TD_PRD_ATTRIBUTE_VALUE.PRD_ATTRIBUTE_VALUE_KEY=TD_PRODUCT.PRD_MANUFACTURER_KEY

Concernant la différence entre PRD_ATTRIBUTE_VALUE (Terra ) et TD_PRD_ATTRIBUTE_VALUE (DWH ), j'ai vu Edouard : En effet il y a eu un nettoyage de la table PRD_ATTRIBUTE_VALUE (projet "valeur privée") mais la procédure est assez complexe (plusieurs scripts : nettoyage produit, garbage collecting...) Bref si l'on veut les scripts je peux les demander a Patrick

Mais malgré cette différence, il manque environ 500 000 enregistrements (voir requête : V:\Reporting\BusinessIntelligence\En Développement\2008-07 Product manufacturer name\nb_prd_attribut_value.sql).
Donc j'ai préparé un script pour récupérer les enregistrements manquants (voir script : V:\Reporting\BusinessIntelligence\En Développement\2008-07 Product manufacturer name\recup_prd_attribut_value.sql)

En conclusion :
- Soit on nettoie et on récupère les enregistrements manquants
- Soit on ne fait que récupérer les enregistrements manquants
- Soit on fait un full sur la table

Julien.
Commentaire de Cedric Favero [ 12/août/08 16:27 ]
J'ai des besoins assez importants pour la cellule anti-contrefaçon.
Pensez vous qu'il soit possible de sortir à court terme des rapports incluant le champ fabricant?

Ex pratique : vendeurs ayant un nombre d'annonces superieur à 10 , rubrique parfums et fabricant Chanel.

Merci d'avance.




[BIN-393] [Cobranding] : rajouter une colonne commision without shipping Création: 04/déc./07 17:55  Mise à jour: 14/janv./08 10:31  Résolue: 27/déc./07 11:42

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Ghislain Gridel Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour Samir,

peux-tu rajouter une colonne "commission amount without shipping" à droite de commission sur les rapports PriceMinister - Captured co-branding overview et PriceMinister - Authorized co-branding overview , stp ?

Merci.

Ghislain

 Commentaires   
Commentaire de Samir Beghdadi [ 27/déc./07 11:42 ]
Bonjour,

Ghislain, comme vu ensemble avec j'ai ajouté deux colonnes "commission amount without shipping" et "VAT on commission amount without shipping" dans les deux rapports PriceMinister - Captured co-branding overview et PriceMinister - Authorized co-branding overview.

Agathe, veux tu les valider stp.

Merci

Samir
Commentaire de Samir Beghdadi [ 02/janv./08 14:26 ]
Bonjour Ghislain,

Les deux rapports "PriceMinister - Captured co-branding overview" et "PriceMinister - Authorized co-branding overview " sont en production.

Merci

Samir
Commentaire de Justin Ziegler [ 08/janv./08 15:29 ]
Guislain,
N'est il pas possible de stopper toute modif sur les rapports de cob ?
il me semble qu'il y a un consensus pour dire que sauf exception on baisse la priorité de ces projets ?
je met OM en copie.
Commentaire de Justin Ziegler [ 08/janv./08 15:30 ]
je vois qu'OM est déja en copie.
Compte tenu des priorité globale de l'équipe bi, je pense qu'on devrait évité de passer plus de temps sur les rapports de cob ! :-)
Commentaire de Justin Ziegler [ 08/janv./08 15:31 ]
D'autant plus qu'on y a deja passé énormément de temps, voire meme cela a été un des plus gros consommateur de temps coté bi.
Commentaire de Ghislain Gridel [ 09/janv./08 18:37 ]
Ok. je comprends que cela ne soit pas une priorité. On peut le reporter à plus tard. Merci.

Ghislain




[BIN-500] [TFV] : différences sur rapport SLTV Création: 17/oct./08 16:30  Mise à jour: 06/mars/09 18:09  Résolue: 06/mars/09 18:09

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Thomas Beylot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Classeur1.xlsx    
Pays:
FRA - France

 Description   
Hello

à une semaine de ma prèz au coex, je me permets de mettre cette question en "critique"
en effet
j'observe certaines différences la plupart du temps non significatives mais parfois oui.

Mais cela ne devrait pas être exactement pareil ?

voir le fichier excel en pj.

thomas

 Commentaires   
Commentaire de Thomas Beylot [ 17/oct./08 16:32 ]
à noter que les rapports confid se trouvent sur http://intra.priceminister.com/stats/reports/confid/executive/seller/macro/
Commentaire de Agathe Remy [ 17/oct./08 16:53 ]
Thomas,

Les différences en faveur du BI jusqu'en janvier mars 2006 peuvent s'expliquer par le fait que le BI prend en compte les annonces archivées contrairement au rapport sur l'ancien système.
Pour les différences en négatif à partir d'avril 2006 (et inférieures à à 4%) peuvent s'expliquer par les mutations de part en pros qui ont eu lieu entre la date de génération du rapport sur l'ancien système et aujourd'hui. A vérifier.

A ta dispo pour en discuter.
Agathe

Commentaire de Agathe Remy [ 06/mars/09 18:09 ]
Suite à la migration des rapports Seller macro dans BI et à la modification de l'arborescence Produit Art&Collection, cette demande devient obsolète.

Agathe




[BIN-547] [BACK-OFFICE] : Ajout de la dimension "Advert serial number" (Univers Advert et Item) Création: 12/janv./09 13:36  Mise à jour: 04/mars/09 11:12  Résolue: 04/mars/09 11:12

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
FRA - France

 Description   
J'aimerais pouvoir detecter les annonces ou les articles pour une annonce donnée en fonction du numéro de serie renseigné (cf capture).
Car on a identifié un certain nombre de numéros de série systematiquement utilisés sur des articles de contrefaçon.

Donc dans le groupe Advert des univers ADVERT et ITEM avoir une dimension "Advert Serial Number"

A moins que çà n'existe déjà? (pas trouvé)

Merci.

 Commentaires   
Commentaire de Agathe Remy [ 16/janv./09 19:07 ]
Bonsoir Cédric,

Nous disposons bien de l'information "Advert serial number" au niveau de la transaction (ITEM).
En revanche, elle a été oubliée lors de la construction de la base BI au niveau de l'annonce (ADVERT).

Nous pouvons donc dans un premier temps l'ajouter dans l'univers ITEM.
En revanche, il faudra attendre un prochain déploiement de l'alimentation (probablement mi-février) pour l'ajouter dans l'univers ADVERT.

Agathe

Commentaire de Cedric Favero [ 19/janv./09 09:38 ]
Ok , faites moi signe alors quand ce sera disponible dans les deux univers.
Merci.
Commentaire de Cedric Favero [ 05/févr./09 18:11 ]
je ne le trouve pas dans Advert
Commentaire de Cyril Tanneau [ 05/févr./09 18:40 ]
Oui, en effet... Comme nous te l'avions dit (voir commentaires du Jira), l'ajout de cette dimension dans Advert nécessite une mise en Prod de notre alimentation, qui n'est prévue que pour mi Février.

Cette dimension a donc été ajoutée dans Item pour le moment, elle le sera dans Advert très prochainement.

Merci,

Cyril
Commentaire de Cedric Favero [ 06/févr./09 09:00 ]
Je pensais que çà faisait partie du lot cette sorti cette semaine.
Relancez moi pour validation quand çà sera bon alors..

Merci.
Commentaire de Cyril Tanneau [ 04/mars/09 11:12 ]
Cédric,

La dimension "Advert serial number" est bien présente dans les deux univers (ITEM et ADVERT) comme demandé dans le Jira.

Les données ont été initialisées et sont donc accessibles dans le BI.

Merci,

Cyril




[IMP-3386] Variations de stock site UK Création: 10/mars/09 09:46  Mise à jour: 30/oct./09 15:48  Résolue: 18/mars/09 15:29

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Gaël Seguillon Attribution: Jérôme Viviès
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
GBR - Royaume Uni
Login: n/a
Séparateur: N/A
Type de traitement:
N/A

 Description   
Bonjour comme j'en ai averti Daniel la semaine dernière nous constatons des variations de stock très importante sur le tableau de bord BO UK ces variations sont inexplicables pour nous car dissociées d'entrées ou sorties de fichiers de stock de pros
pour exemple + variation de -6 millions de livres entre le 09 et 10 Mars de 23 millions à 17 millions à l'inverse la semaine passée augmentation du stock de jeux vidéo de 6000 à 50 000 alors que nous n'avons pas vu passé de gros fichier de pros ?
merci de nous éclaircir sur l'origine de ces variations et nous assurer que les valeurs du tableau de bord sont le reflet de la réalité du stock en ligne.
Gaël

 Commentaires   
Commentaire de Gaël Seguillon [ 10/mars/09 09:47 ]
Erreur dans le menu déroulant il s'agit bien d'une demande sur le site UK
Commentaire de Jérôme Viviès [ 10/mars/09 13:26 ]
Ok, j'ai repassé le JIRA côté IMP et j'ai corrigé le pays (FR => UK).
Commentaire de Gaël Seguillon [ 10/mars/09 13:27 ]
merci Jérôme j'ai été un peu vite en le validant
Commentaire de Frédéric Nahum [ 16/mars/09 16:52 ]
j'ai vérifier aujou'd'hui le stock est revenu a la normal soit 30 million d'article, je vais vérifier demain et parès demain pour voir si cela se reproduit je vous tiens au courant
Commentaire de Gaël Seguillon [ 16/mars/09 17:10 ]
Je pense que la variation n'est pas logique, comment pouvons nous avoir plus de 78 000 en stock jeux vidéo alors qu'aucun pros n'a fait d'import important su cette catégorie depuis plusieurs semaines ?
Commentaire de Frédéric Nahum [ 16/mars/09 18:13 ]
Attention il s'agit du nombre d'article (annonces x quantité) donc il suffit de 700 annonces avec des quantités de 100 et Hop et on déja 70 000
Commentaire de Gaël Seguillon [ 16/mars/09 18:29 ]
Tu peux identifier les annonces avec beaucoup de profondeur de stock sur le UK.
Commentaire de Gaël Seguillon [ 16/mars/09 18:30 ]
juste sur le JV ?
merci
Gael
Commentaire de Frédéric Nahum [ 18/mars/09 10:52 ]
JV ??
Commentaire de Jérôme Viviès [ 18/mars/09 11:08 ]
Jeu Vidéo
Commentaire de Jérôme Viviès [ 18/mars/09 15:28 ]
Gaël,

Afin d'avoir un récap un peu construit :

a/ Comme le signale Fred : ce qui est vu dans le BO est le nombre d'articles (=annonces x quantité)

b/ Il n'est pas exact de dire qu'aucun pro n'a fait de l'import sur les différentes catégories sur les jours observés.
Mais plutôt :
- aucun nouveau pro n'est arrivé par import ce jour là.
- les pros existant ont fait des mises à jour de leur stock, qui peuvent être conséquentes - comme l'indiquait Fred, il suffit de 70 annonces à quantité 100 pour que les chiffres bondissent.
Exemple : passage à 78.000 articles jeux vidéo le 12 mars = import inandout (notamment) de 15000 articles (2800 annonce * quantité 3 + 900 annonces * quantité 8)

c/ Nous avons une alerte mail qui nous informe des grosses variations de stock, mais n'avons pas d'outil qui permette d'identifier les pros ou de lister les pros par « profondeur de stock » (classement par nombre d'annonces ou d'articles) - mais peut-être est-ce faisable dans Business Object ?
Nous essayons parfois d'expliquer les variations, mais vu le manque d'outil, ce n'est pas systématique aujourd'hui. En gros nous devons fouiller dans le back-office dans le détail des fichiers traités ce jour là...

Conclusion :
- Les chiffres du BO son fiables et reflètent des vrais mouvements de stock initiés par les pros.
- Si vous avez un doute ponctuel => JIRA, comme tu as fait.
- Si vous avez besoin de l'info systématiquement, on peut en parler, et aussi à PKR et JZ afin qu'on déclenche un projet là-dessus.
Et / ou si vous voyez un moyen de produire un rapport BI... pourquoi pas ? - nous serions preneurs (!)
Commentaire de Gaël Seguillon [ 18/mars/09 15:43 ]
ok merci je vais voir ce que l'on peut avoir via le BI mais pour l'instant le BI UK n'existe pas encore...
C'est rassurant de savoir que les données tableau bord BI UK sont fiables. on a beacuoup de stock jeux qui est arrivé de pros qui n'étaient pas censés en vendre, je suis aller voir le stock de Inandout et il a effectivement du stock en JV ainsi que d'autres vendeurs qui étaient spécialisés musique, c'est la diversification de pros existants qui a généré cette montée rapide du nombre de références.





[BIN-586] [Marketing] : Nouveau rapport de suivi des ventes effectives par tracking Création: 28/mai/09 13:12  Mise à jour: 28/janv./10 13:26  Résolue: 30/oct./09 15:07

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Ghislain Gridel Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word BRIEF+NOUVEAU8RAPPORT+SUR+LA+VENTEv1.doc     Microsoft Word DMR - Rapport Daily item followup by advert tracking and product family v1.0.docx     Microsoft Excel Maquette.xls    
Pays:
FRA - France

 Description   
Bonjour,

Dans la continuité du rapport sur les mises en vente, et toujours dans l'objectif de suivre et analyser les résultats sur la vente par canal marketing (voir premier brief), nous aurions besoin d'un rapport sur les ventes effectives.

--> Objectifs
Actuellement, les ventes effectives ne sont pas suivies par canal en last tracking 30 jours. Les équipes Acquisition et Fidélisation ont de forts objectifs en recrutement de nouveaux vendeurs en 2009. Ces objectifs sont quantitatifs et qualitatifs. Nous souhaitons pouvoir mesurer, quantifier et qualifier l'acquisition des nouveaux vendeurs, aussi bien à partir du trafic venant de nos partenaires, que des actions mises en place part l'équipe fidélisation : Newsletter vente, CRM et opérations diverses. Nous aurions besoin de la mise en place d'un rapport spécifique sur les ventes effectives.

Le brief est ci-joint.

j'aimerai discuter avec vous pour voir ce qu'on met dans le volume d 'affaire/commission capturé/autorisé. Merci

A votre dispo.

Ghislain


 Commentaires   
Commentaire de Dalila Belkebir [ 30/sept./09 17:28 ]
Ghislain,

Voici ce que nous avions vu ensemble lors d'un point le 22/09 :

Sur ce reporting, la notion de 1ère vente effective nécessiterait une évolution technique couteuse que nous ne pourrons mettre en place que si cette notion est susceptible d'être utilisée pour d'autres besoins.
Il faut donc d'abord nous préciser ces autres besoins afin que nous puissions analyser au mieux la solution technique à mettre en place (et optimiser son coût de mise en place).
En attendant cette analyse, je te propose de développer le rapport sans cette notion. Cette notion pourra alors être développé ultérieurement.

Lors de la réunion BI MKT de lundi 28/09, Odile m'a signifié son accord pour un développement en 2 phases :
- lot1 : sur Q4 2009 le Tdb sans la notion de première vente effective
- lot2 : à planifier sur 2010, l'ajout de la notion de première vente effective, après étude des besoins associés

Pourrais tu STP me le valider afin que je puisse lancer les spécifications et les développements associés ?
merci.

Dalila.
Commentaire de Ghislain Gridel [ 30/sept./09 18:15 ]
Salut dalila,

 ok pour 2 lots. nous prenons en compte cela pour nos budgets.
Commentaire de Julien Girardet [ 07/oct./09 14:37 ]
Salut Ghislain,

Ci joint la maquette que nous avons validé hier.

j'attends ton retour sur le type produit. Actuellement le rapport est uniquement sur le type de produit.

Merci.

Julien.
Commentaire de Julien Girardet [ 07/oct./09 14:38 ]
correction :

Actuellement le rapport est uniquement sur la FAMILLE de produit.

Julien.
Commentaire de Ghislain Gridel [ 07/oct./09 17:26 ]
Après discussion avec thomas, il faut rajouter le type de produit. Merci
Commentaire de Julien Girardet [ 13/oct./09 12:17 ]
Ghislain,

voici les specifications du rapport.
En attente de ta validation. Ainsi nous pourrons commencer les developpements.

Merci

Julien
Commentaire de Ghislain Gridel [ 13/oct./09 17:48 ]
ok pour moi. Merci
Commentaire de Dalila Belkebir [ 30/oct./09 15:07 ]
Bonjour,

Le nouveau rapport suivant a été livré en production dans ITEM :

Daily item follow up by advert tracking and product family

Merci de vos retours pour validation.

Cdlt,
Dalila.

Commentaire de Dalila Belkebir [ 28/janv./10 13:26 ]
Odile,

Comme vu avec toi en point MKT BI du 18/01/2010, cette demande est OK.

Cdlt,
Dalila.




[BIN-636] [Marketing] : Extract cible pour op mailing postal Colissimo_PriceMinister Création: 23/nov./09 11:20  Mise à jour: 26/janv./10 17:37  Résolue: 30/nov./09 16:39

Etat: Fermé
Projet: Business Intelligence
Composants: Partners
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Charlotte Fachan Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut Dalila,

nous allons (re)mettre en place une opération cobrandée avec colissimo.fr, du 25/12 au 30/01, sur le thème de la revente des cadeaux de Noël,en reprenant le dispositif mis en place dans le cadre de l'opération de septembre.
Ainsi nous avons prévu d'envoyer un mailing postal sur 3 cibles distinctes :
Cible 1 : clients ayant déjà utilisé le service (op sept / oct) => soit une estimation de 3 000 clients
Cible 2 : Clients vendeurs PriceMinister avec adresses nettoyées (dédoublonnées du fichier du mailing de sept/ oct et des clients ayant bénéficié de l'offre) => soit une estimation d'environ 25 000 clients
Cible 3 : Client base colissimo.fr (dédoublonnés du fichier du mailing de septembre / octobre et des clients ayant bénéficié de l'offre des 3¿)=> soit une estimation d'environ 22 000 clients

Pour ce faire, j'aurais besoin d'un extract pour la cible 2
Vendeurs particuliers hors cobrandé ayant réalisé au moins 2 ventes, pas de blacklist, pas de fraudeur, pas de claims, avec adresse postale de paiement en France.

Avec les champs suivants :
- Id user
- Civilité
- Nom
- Prénom
- Adresse
- Code postal
- ville

est-il également possible d'avoir un classement par adresses email invalides? avez -vous cette info?

L'extract sera ensuite envoyé à PNDATA pour un redressement des adresses postales.
Il faudrait donc prévoir un stock de 40 000 contact.

Il me faudrait cet extract pour le 30/11 au plus tard.

Merci
Charlotte



 Commentaires   
Commentaire de Dalila Belkebir [ 24/nov./09 10:20 ]
Bonjour Charlotte,

Nous n'avons malheureusement pas l'info : "adresse email invalide". Nous ne pouvons donc pas te faire un classement sur la base de cette info.

D'après ma première analyse l'extraction suivante me semble faisable par le BI :
Vendeurs particuliers hors cobrandé ayant réalisé au moins 2 ventes, pas de blacklist, pas de fraudeur, pas de claims, avec adresse postale de paiement en France.
Avec les champs suivants :
- Id user / Civilité / Nom / Prénom / Adresse / Code postal / ville

Cela me semble représenter une cible plus grande que 25 000 PMembers.
As-tu une condition sur date ou bien souhaites-tu requêter sur l'ensemble des PriceMembers ? Ceci pourra être vu lorsque Julien fera la requête ainsi que son analyse de volumétrie.

Je laisse Julien regarder cela d'un peu plus près et te faire part de ces éventuelles demandes de précision.

Nous travaillons actuellement sur le projet Question/Réponses mais ton extraction pourra être faite d'ici le 30/11.

Cordialement,
Dalila.
Commentaire de Charlotte Fachan [ 24/nov./09 14:43 ]
ok merci Dalila !
Passons nous du classement par "adresse email invalide".

Effectivement le volume sera supérieur à 25 000 PMembers. Sachant que les adresses vont être ensuite redréssées par PN DATA il nous faut un volume bien supérieur pour être sûr dévoir 25 000 adresses "propres" au final.

A ta dispo pour en parler.

Charlotte
Commentaire de Julien Girardet [ 27/nov./09 11:28 ]
Salut Charlotte,

Avec les critères suivants, j'obtiens environ 100 000 users :
- vendeurs particuliers
- hors cob
- ayant réalisés au moins 2 ventes cloturées depuis Janv 2009
- sans claim
- pas fraudeur
- ayant une adresse de paiement en France.

Souhaites tu modifier la periode pour augmenter/diminuer la volumetrie ?

Julien.


Commentaire de Charlotte Fachan [ 30/nov./09 10:25 ]
Merci Julien,

C'est parfait !
Partons sur ce volume. Peux tu m'envoyer l'extract ?

Merci
Charlotte
Commentaire de Julien Girardet [ 30/nov./09 16:39 ]
L'extract est dispo ici : T:\BI\01 - Demandes ponctuelles\2009-12 Extract OP colissimo JIRA BIN-636

Julien.
Commentaire de Charlotte Fachan [ 30/nov./09 16:48 ]
Super merci !
je transmets à PNDATA.

Charlotte




[EXP-1963] Gestion des adresses IP en interne pour les cobrnadings Création: 05/mai/06 15:36  Mise à jour: 25/juin/07 18:57  Résolue: 17/mai/06 12:42

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Sébastien Tournay Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 2 heures, 50 minutes
Estimation originale: Non spécifié


 Description   
Une bonne façon d'économiser des adresses IP...

Je viens de me rendre compte sur notre zone que nous avions une adresse IP par cobranding. En fait, ce n'est pas utile ;-)) On peut utiliser une seule adresse IP pour tous les cobrandings (ofup, m-.pm.lan..) puisque apache est configuré en virtualhost par nom. C'est le fonctionnement que nous avons en PROD. Je ne suis même pas certain qu'il soit utile d'avoir une @IP différente pour www.pm.lan bo.pm.lan comme nous l'avons en PROD. C'est surtout utile lorque le vont gérer des VIP pour la répartition de charge mais en INTEG.. pas besoin.

Il faudrait donc faire du ménage dans les @IP pour en libérer et adapter la conf APACHE en conséquence. On devrait récupérer quelques adresses.. ATTENTION aussi à libérer les @IP virtuelle associées à la carte réseau de DEUTZ.



 Commentaires   
Commentaire de Pap Ndiaye [ 15/mai/06 13:56 ]
On prevoit cela en fin de semaine
Commentaire de Jérémie Bennejean [ 17/mai/06 12:41 ]
C'est bon je m'en suis occupé.

En résumé : 26 adresses IP ont été libérées sur les 31 cobrandings.
5 cobrandings ont conservés des @ IP:
pm-es
www
bo
preview
bi

Modification sur Deutz :
httpd.conf
Modification des virtuals hosts concernés --> pointent sur 192.168.1.90
restart et graceful de httpd

/etc/sysconfig/network-scritp
plutot que de supprimer les interfaces, je les ai renommé en .old au cas ou.
redémarrage de la carte réseau

Modification sur ruinart
Zone DNS
pm.lan.zone
redémarrage du DNS

Test de cobrandings liberation.pm.lan , m6.pm.lan, etc ...
Commentaire de Sébastien Tournay [ 17/mai/06 17:45 ]
Très bien. Il devient donc moins critique d'étendre la plage d'@IP. Peux tu nous l'inventaire des @IP que nous avons maintenant de dispo sur notre plage ?
Commentaire de Jérémie Bennejean [ 18/mai/06 10:59 ]

Nous avons économisé 24 adresses IP
La pluspart de cobrandings pointent sur 192.168.1.90 (ceux resté inschangés sont pm-es,liberation,www,bo,preview,bi,freesurf)

Au total nous disposons sur la plage fixe (192.168.1.1-->192.168.1.99) de 56 adresses IP de libres ( rien que sur la plage fixe)




[BIN-630] [Executive] Extract témoignages textes PriceMembers pour faciliter localisation de témoins RP Création: 29/sept./09 14:59  Mise à jour: 27/oct./09 10:02  Résolue: 07/oct./09 18:02

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Pierre Krings Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
PriceMinister est constamment sollicité par des journalistes qui souhaitent faire un sujet sur PM mais ont besoin de vrais membres pour témoigner de leur activité sur le site. Malgré (ou à cause) de la taille de la base client, il n'est pas facile de trouver des candidats potentiels susceptibles de parler de Price.
L'idée est de faire une pré-sélection en se basant sur des membres qui ont pris la peinne de faire des témoignages écrits sur le site, à partir des formulaires "Mon histoire avec PriceMinister" et "Mon expérience avec PriceMinister".
Il faudrait réaliser un extract de ces témoignages pouvant être visualisé dans excel, et associer des informations (sexe, age, géographie, acheteur / vendeur) susceptible d'aider à cibler. Basé sur le contenu du témoignage de la sélection, les membres pourront alors être contactés par téléphone.

Infos requises :

Login
Sexe (si renseigné)
Date de naissance (si renseignée)
Date de création compte
Nbre de ventes
Nbre d'achats
Type vendeur
Date de dernière connexion
Pays dernier achat (si renseigné)
CP dernier achat (si renseigné)
CP coordonnées vendeur (si renseigné)
Date du message
Titre du message
Contenu du message

Un extract one-shot pouvant être relancé de temps en temps semble suffisant.


 Commentaires   
Commentaire de Dalila Belkebir [ 07/oct./09 18:02 ]
Bonjour Pierre,

J'ai réalisé un extract avec les données que j'ai pu récupérées.
Tu trouveras l'extract dans le répertoire :
T:\BI\01 - Demandes ponctuelles\00 - Etudes PKR\Extraction des Members avec une Histoire avec PM


Je n'ai pas inséré les données de type Nbre de ventes & Nbre d'achats car la requête a tourné sur TERRA afin d'obtenir le contenu du mail (non récupéré dans BI). J'y ai par contre inséré la note du vendeur afin de donner un avis sur la "qualité" du vendeur.
Si tu souhaites vraiment ces infos je pourrais pousser un peu amis cela risque de me prendre du temps.

Fais moi part de tes retours.

Cdlt,
Dalila.
Commentaire de Pierre Krings [ 07/oct./09 18:35 ]
Merci.

Bien compris sur le nbre d'achats et de ventes.
Concernant la note du vendeur, il y a des très grandes valeurs. C'est le cumul des notes ? Dans ce cas, c'est parfait puisque ça renseigne sur la grosseur du vendeur plus que sur ça qualité, mais c'est très bien !

Il manque la date de naissance et le CP vendeur. C'est compliqué de les ajouter ?

Le plus gros souci : les témoignages s'arrêtent à février 2006. Il n'y a que les messages qui ont pour titre "Dites-nous tout sur votre histoire avec PriceMinister". Ca vient peut-être de là.
Idéalement, il faudrait tous les messages adressés à la boîte de messagerie "mktg ENQUETES". Et là on aura tout normalement.

p

Commentaire de Dalila Belkebir [ 22/oct./09 11:37 ]
Bonjour Pierre,

J'ai sorti une nouvelle extraction de données sur la base des mails
'Dites-nous tout sur votre histoire avec PriceMinister',
'Mon expérience avec PriceMinister',
'Mon histoire avec PriceMinister'

Tu la trouveras dans le répertoire :
T:\BI\01 - Demandes ponctuelles\00 - Etudes PKR\Extraction des Members avec une Histoire avec PM

N'hésite pas à nous communiquer tes retours !

Cdlt,
Dalila.
Commentaire de Dalila Belkebir [ 27/oct./09 10:02 ]
De : Pierre Krings [mailto:pierre.krings@priceminister.com]
Envoyé : jeudi 22 octobre 2009 17:10
À : 'Dalila Belkebir (JIRA)'
Objet : RE: [JIRA] Mise à jour: (BIN-630) [Executive] Extract témoignages textes PriceMembers pour faciliter localisation de témoins RP

Ca a l'air bon. Merci !

Pierre Krings
PriceMinister
57 Boulevard de la Villette
F75010 Paris - France
T: +33 (0)1 42 78 79 77
F: +33 (0)1 42 78 80 61
http://www.priceminister.com




[APP-29252] Paniers capturés sans montant coupon capturé Création: 19/avr./10 14:29  Mise à jour: 04/mai/10 18:15  Résolue: 04/mai/10 15:28

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 66.0.1
Version(s) corrigée(s): 68.0.1

Type: Bogue Priorité: Critique
Rapporteur: Julien Girardet Attribution: Arnaud Forgues
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel bug_APP-29252-cible-panier.xls     Microsoft Excel purchase_id.xls     Microsoft Excel PURCHASE_ID_280410.xlsx    
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***

 Description   
Bonjour,

Sur le mois d'Avril (04/2010), 47 paniers capturés ont un montant capturé < au montant total du panier.
Ce sont des paniers avec coupons (secret name = FQPAF6, coupon_model_id = 696378), capturés mais avec un montant coupon capturé = 0.

Nombre de paniers victimes du bug par jour :
AUTHORIZATION_DATE COUNT(PURCHASE_ID)
03/04/2010 5
04/04/2010 18
05/04/2010 13
06/04/2010 4
07/04/2010 4
08/04/2010 2
09/04/2010 1

Ci-joint la liste des purchase_id victimes du bug (fichier excel).


Julien.


 Commentaires   
Commentaire de Claire Durand [ 26/avr./10 12:05 ]
Salut,

encore des paniers en capture denied + coupon FQPAF6
Je croyais que ce pblème était réglé ?

Pouvez vous me tenir au courant ?

ex de panier récent : http://bo.priceminister.jmh/purchase_back?action=purchaseview&purchaseid=85604562

Merci
Claire
Commentaire de Arnaud Forgues [ 26/avr./10 13:58 ]
Non, le problème qui a été réglé est le fait que les paniers qui doivent tomber en CAPTURE DENIED, ne le faisaient pas et du coup, on ne pouvait pas identifier ce genre de problème là. Ici le souci est lié au type de coupon (CRM_STANDARD) et le fait :
- qu'il inclus les FdP dans la réduction
- que sa politique d'annulation soit CANCELCASE_STANDARD et non CANCELCASE_NICE

Ces 2 critères de stratégie coupon ne sont pas compatible car pour les coupons avec une politique d'annulation CANCELCASE_STANDARD, on annule un coupon lors de sa capture en vérifiant si la somme des montants des articles (hors FdP, CBV et EG) est inférieur au montant du coupon, ce qui peut etre le cas, sin on a des FdP élevé.

Cela ne s'était pas produit auparavant car cette politique d'annulation était toujours couplées avec une statégie coupon d'exlusion des FdP, hors depuis peu (projet WS Coupon lot 2 livré en TX-M) les coupons CRM_STANDARD et CRM_FIRST_COUPON possèdent ces 2 critères de statégie.

2 solutions possibles pour résoudre le problème :
- appliquer une politique d'annulation CANCELCASE_NICE aux types de coupons CRM_STANDARD et CRM_FIRST_COUPON
- corriger la règle CANCELCASE_STANDARD pour qu'elles prennent en compte l'inclusion/exclusion des FdP (+ pareil pour CBV et EG)

D'autre part, il faudra corriger les 47 cas identifiés par le BI + les nouveaux dont Claire parle.

NB : le bug reste tout de même assez peu fréquent car il faut regrouper pas mal de facteurs : coupon d'un des 2 types sus-cités, avec un montant minimum au double du montant de la réduction (ce qui est le cas pour FQPAF6 : 12 euros pour 6 euros de réduction) ou pas beaucoup plus, et enfin un montant d'articles inférieur à 6 euros mais dont les FdP sont suffisamment élevés (donc plus de 6 euros) pour qu'on dépasse les 12 euros et que le coupon soit accepté !
Commentaire de Claire Durand [ 26/avr./10 15:29 ]
Merci pour ta réponse Arnaud. Concernant tes 2 solutions, qui est sensé pouvoir prendre une décision ? Steven ?
Commentaire de Steven Harel [ 27/avr./10 09:07 ]
C'est plutôt le marketing qui gère ce genre de choses.

Commentaire de Emeric Teil [ 27/avr./10 10:15 ]
Hello,
j'en ai déjà parlé avec eux hier, le souci c'est qu'Odile n'est pas là et que l'impact de cette décision concerne plutôt le budget donc...
Commentaire de Cédric Goldovsky [ 27/avr./10 11:07 ]
il faudrait préciser une nouvelle version cible
Commentaire de Julien Girardet [ 27/avr./10 18:31 ]
Pour info, le bug continue.
On en est à 58 paniers victimes du bug, toujours avec coupon (secret name = FQPAF6, coupon_model_id = 696378)

Nombre de paniers victimes du bug par jour :
AUTHORIZATION_DATE COUNT
03/04/2010 5
04/04/2010 18
05/04/2010 13
06/04/2010 4
07/04/2010 4
08/04/2010 2
09/04/2010 1
10/04/2010 2
11/04/2010 2
12/04/2010 2
13/04/2010 1
16/04/2010 1
17/04/2010 1
19/04/2010 2

Commentaire de Julien Girardet [ 28/avr./10 11:07 ]
Purchase_id victimes du bug sur 04/2010 jusqu'au 28/04/2010
Commentaire de Arnaud Forgues [ 30/avr./10 15:31 ]
Concernant la correction applicative, Emeric a vu et validé avec PKR que l'on partait sur la 2e option : on adapte donc la règle CANCELCASE_STANDARD afin qu'elle prenne en compte l'inclusion (ou non) des FdP pour déclencher l'annulation du coupon lors de la capture et ainsi éviter ce genre de bug.

Pour l'historique, un script va traiter les 59 paniers(1 de plus : 85604562) actuels concernés en :
- repassant l'état du coupon de CANCELLED à CAPTURED
- affectant le bon montant au coupon capturé dans le panier (purchase.capture_coupon_amount) déduit à partir du montant total du panier (articles + FdP + CBV + EG) moins le montant déjà capturé + un petit évènement sur le panier pour garder une trace
- supprimant (passage de OPEN à DELETED) le nouveau coupon CRM_STANDARD généré pour chaque utilisateur concernés suite à l'annulation malencontreuse du bon coupon (si celui-ci a déjà été utilisé, alors on ne fera rien à part logguer l'information)

Le script est dans V:/Database/TX-N/dev/TX-N_APP-29252_01_FR_clean_purchases.sql

La cible et les montants ont été vérifiés avec le BI, ono va donc pouvoir lancer une premiere fois le script. Par la suite on pourra le relancer suite au déploiement de la correction applicative lors du patch V68.0.1 afin de traiter les derniers cas qui seront apparu entre temps.
Commentaire de Cédric Goldovsky [ 03/mai/10 10:41 ]
Note pour l'integ :
Panier de test KO : 81285338 (nom du coupon annulé et recréé : "APP29252")
après script : vérifier la capture
avec nouvelle appli : refaire le même achat avec un autre compte + même coupon & paiement PMV
Commentaire de Arnaud Forgues [ 03/mai/10 11:42 ]
Le correctif applicatif est commité sur le tronc pour déploiement en V68_0_0 ou V68_0_1 (à l'integ et Manu de voir)

Il ne reste donc plus qu'à passer le script de correction pour les 59 paniers en PROD (+ les autres qui aopparaitont d'ici le déploiement du correctif)

[CAJ2010Q2TX]
Commentaire de Arnaud Forgues [ 03/mai/10 11:46 ]
Je réouvre le JIRA en attendant de pouvoir faire le commit :-)
Commentaire de Arnaud Forgues [ 04/mai/10 11:25 ]
Le script a été passé en PROD et a corrigé les 62 paniers (3 nouveaux depuis hier) actuellement concernés.

Voici la liste exhaustive (via les logs du scripts) :

Updating purchase 84826000 and coupon 89653218 with an amount of 3.4
Deleting coupon 89881059 for user 19684994
Updating purchase 84794797 and coupon 89648869 with an amount of 6
Deleting coupon 89881024 for user 13276541
Updating purchase 84796285 and coupon 89131331 with an amount of 6
Deleting coupon 89881030 for user 20100697
Updating purchase 84799473 and coupon 89192993 with an amount of 6
Deleting coupon 89881033 for user 20321127
Updating purchase 84799751 and coupon 89378173 with an amount of 6
Deleting coupon 89881036 for user 19987873
Updating purchase 84800230 and coupon 89647579 with an amount of 6
Deleting coupon 89881041 for user 19750771
Updating purchase 84801368 and coupon 89648087 with an amount of 6
Deleting coupon 89881040 for user 16553949
Updating purchase 84802221 and coupon 89332071 with an amount of 6
Deleting coupon 89653581 for user 19349490
Updating purchase 84807938 and coupon 89651645 with an amount of 6
Deleting coupon 89881045 for user 14489811
Updating purchase 84811020 and coupon 89652216 with an amount of 6
Deleting coupon 89881051 for user 20360852
Updating purchase 84811064 and coupon 89021385 with an amount of 6
Deleting coupon 89881046 for user 18920037
Updating purchase 84811590 and coupon 89331372 with an amount of 6
Deleting coupon 89881049 for user 19339834
Updating purchase 84812029 and coupon 89652191 with an amount of 6
Deleting coupon 89881050 for user 19253633
Updating purchase 84814986 and coupon 89303493 with an amount of 6
Deleting coupon 89881053 for user 15361094
Updating purchase 84819330 and coupon 89369879 with an amount of 6
Deleting coupon 89881054 for user 19842833
Updating purchase 84823638 and coupon 89653197 with an amount of 6
Deleting coupon 89881057 for user 19704225
Updating purchase 84824784 and coupon 88917205 with an amount of 6
Deleting coupon 89881058 for user 17618106
Updating purchase 84826405 and coupon 89132786 with an amount of 6
Deleting coupon 89881060 for user 16204928
Updating purchase 84832481 and coupon 89653229 with an amount of 3.1
Deleting coupon 89881061 for user 18788070
Updating purchase 84833486 and coupon 89651420 with an amount of 6
Deleting coupon 89881063 for user 19710829
Updating purchase 84837016 and coupon 89669427 with an amount of 6
Deleting coupon 89881064 for user 1787006
Updating purchase 84843561 and coupon 89667352 with an amount of 6
Deleting coupon 89881066 for user 19943007
Updating purchase 84843661 and coupon 89669344 with an amount of 6
Deleting coupon 89881065 for user 20400503
Updating purchase 84845825 and coupon 89665613 with an amount of 6
Deleting coupon 89881068 for user 19536954
Updating purchase 84858001 and coupon 89680419 with an amount of 6
Deleting coupon 89881069 for user 20019235
Updating purchase 84863493 and coupon 89680659 with an amount of 6
Deleting coupon 89881071 for user 20426166
Updating purchase 84863606 and coupon 89309053 with an amount of 6
Deleting coupon 89881072 for user 18970668
Updating purchase 84867937 and coupon 89680449 with an amount of 6
Deleting coupon 89881074 for user 17851053
Updating purchase 84869263 and coupon 89112198 with an amount of 6
Deleting coupon 89881073 for user 19895024
Updating purchase 84877551 and coupon 89517274 with an amount of 6
Deleting coupon 89881075 for user 19809174
Updating purchase 84880934 and coupon 89168451 with an amount of 6
Deleting coupon 89881078 for user 20129021
Updating purchase 84881050 and coupon 89689503 with an amount of 6
Deleting coupon 89881079 for user 17084291
Updating purchase 84886145 and coupon 89689710 with an amount of 6
Deleting coupon 89881080 for user 18110420
Updating purchase 84888405 and coupon 89350311 with an amount of 6
Deleting coupon 89881081 for user 15975521
Updating purchase 84889761 and coupon 89680346 with an amount of 6
Deleting coupon 89881082 for user 20169600
Updating purchase 84892436 and coupon 89689642 with an amount of 6
Deleting coupon 89886501 for user 226131
Updating purchase 84893302 and coupon 89679840 with an amount of 6
Deleting coupon 89886502 for user 19632264
Updating purchase 84897334 and coupon 89704590 with an amount of 6
Deleting coupon 89886503 for user 16226954
Updating purchase 84919438 and coupon 89129385 with an amount of 6
Deleting coupon 89886504 for user 20100391
Updating purchase 84920518 and coupon 89285433 with an amount of 6
Deleting coupon 89886507 for user 18505874
Updating purchase 84935918 and coupon 89653404 with an amount of 6
Deleting coupon 89931599 for user 19840551
Updating purchase 84941658 and coupon 89751808 with an amount of 6
Deleting coupon 89931602 for user 20400908
Updating purchase 84945947 and coupon 89751296 with an amount of 6
Deleting coupon 89931603 for user 18202105
Updating purchase 84969516 and coupon 89649753 with an amount of 6
Deleting coupon 89931604 for user 18502626
Updating purchase 85009306 and coupon 88678460 with an amount of 6
Deleting coupon 89955807 for user 10121992
Updating purchase 85030157 and coupon 89808395 with an amount of 6
Deleting coupon 90687315 for user 20434360
Updating purchase 85059146 and coupon 89828803 with an amount of 6
Deleting coupon 90687316 for user 20221145
Updating purchase 85090331 and coupon 89840139 with an amount of 6
Deleting coupon 90755611 for user 14713038
Updating purchase 85107988 and coupon 89842600 with an amount of 6
Deleting coupon 90755612 for user 19489001
Updating purchase 85133381 and coupon 89114868 with an amount of 6
Deleting coupon 90755623 for user 19930376
Updating purchase 85135095 and coupon 89844968 with an amount of 6
Deleting coupon 90755614 for user 14648398
Updating purchase 85184573 and coupon 89879757 with an amount of 6
Deleting coupon 90755615 for user 20150745
Updating purchase 85186063 and coupon 89881996 with an amount of 6
Deleting coupon 90755617 for user 20428116
Updating purchase 85201891 and coupon 89882934 with an amount of 6
Deleting coupon 90786957 for user 18859928
Updating purchase 85371006 and coupon 89186035 with an amount of 6
Deleting coupon 90943289 for user 20254401
Updating purchase 85407565 and coupon 88895998 with an amount of 6
Deleting coupon 90807706 for user 17303952
Updating purchase 85478492 and coupon 90756619 with an amount of 6
Deleting coupon 90943290 for user 18719723
Updating purchase 85483594 and coupon 90756741 with an amount of .7
Deleting coupon 90848390 for user 17024745
Updating purchase 85604562 and coupon 90848545 with an amount of 6
Deleting coupon 91033726 for user 17751610
Updating purchase 85662617 and coupon 88739800 with an amount of 6
Deleting coupon 91054916 for user 14948018
Updating purchase 85728297 and coupon 88834346 with an amount of 6
Deleting coupon 91054917 for user 16622419
Updating purchase 86016108 and coupon 91083550 with an amount of 6
Deleting coupon 91137692 for user 19322422
Nb of purchase updated : 62




[BIN-643] SECOND EXTRACT Kdo fid vendeur (supplément femmes) Création: 05/janv./10 15:19  Mise à jour: 06/janv./10 11:05  Résolue: 06/janv./10 11:05

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Charlotte Fachan Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File RQT_2nd_extract.sql    
Pays:
FRA - France

 Description   
Comme discuté ensemble, ci dessous les nouveaux critères de ciblage pour réussir à trouver au minimum 1400 "fidèles vendeuses"

Vendeurs particuliers
- avec civilité Mlle ou Mme
- ayant généré entre 70¿ et 90¿ de com nette
- ayant réalisé au min 10 ventes
- et dont l'année de la dernière vente est 2009 (26 523)

Cet extract devra ensuite être redressé par PNDATA (jeudi). La volumétrie doit donc être assez conséquente (au moins deux fois supérieur au volume manquant initial).

Ps : Merci de bien inclure les ID user dans les champs pour pn data

a votre disp pour en parler.
Charlotte


 Commentaires   
Commentaire de Cyril Tanneau [ 05/janv./10 16:01 ]
Charlotte,

j'ai regardé à nouveau la requête pour l'extract.

En conservant le critère initial "entre 12 et 40 ventes confirmées" et en descendant la commission nette générée "entre 70 et 90 Euros", j'obtiens 4411 vendeuses (civilité Mlle ou Mme), ce qui correspond à 3 fois le nombre manquant de vendeuses. Du coup, après avoir redressé les adresses, le compte sera bon...

Est-ce que cela te convient?

Merci,

Cyril
Commentaire de Charlotte Fachan [ 05/janv./10 16:34 ]
super !
partons là dessus.
Tu confirmes que tu as bien exclu du ciblage les critères du premier extract?

Merci
Charlotte
Commentaire de Cyril Tanneau [ 05/janv./10 18:28 ]
Charlotte,

l'extract Extract_2_vendeuses.xls est disponible dans le répertoire T:\BI\01 - Demandes ponctuelles\02 - Etudes Marketing\2009 10 Etude CFA extract_vendeurs_part

nous avons bien:
- les vendeurs particuliers enregistrant:
 - entre 12 et 40 ventes capturées (Bornes comprises)
 - généré une commission PM capturée net >=70 et <90 Euros
 - dernière vente capturée en 2009
- Femmes (melle ou Mme uniquement)

Pas de risque de doublon avec l'ancien extract puisque nous avons une comm. nette capturée strictement supérieure à 90E.

Commentaire de Cyril Tanneau [ 05/janv./10 18:30 ]
Charlotte,

l'extract Extract_2_vendeuses.xls est disponible dans le répertoire T:\BI\01 - Demandes ponctuelles\02 - Etudes Marketing\2009 10 Etude CFA extract_vendeurs_part

nous avons bien:
- les vendeurs particuliers enregistrant:
 - entre 12 et 40 ventes capturées (Bornes comprises)
 - généré une commission PM capturée net >=70 et <90 Euros
 - dernière vente capturée en 2009
- Femmes (melle ou Mme uniquement)

Pas de risque de doublon avec l'ancien extract puisque nous avons une comm. nette capturée strictement supérieure à 90E.

Merci,

Cyril
Commentaire de Charlotte Fachan [ 06/janv./10 10:48 ]
Super ! merci Cyril
Charlotte




Installation du nouveau serveur destiné à FAST en intégration (EXP-942)

[EXP-1226] Upgrade CPU sur KRUG Création: 09/févr./06 12:38  Mise à jour: 25/juin/07 18:56  Résolue: 17/févr./06 11:04

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Sébastien Tournay Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 2 heures, 30 minutes
Estimation originale: Non spécifié


 Description   
Vu les mesures de PERF sur KRUG pour l'indexer, il nous manque de la CPU.

Jérémie, Peux tu avoir avec DELL pour ajouter 2 CPU supplémentaire à KRUG. Est-ce possible sur le 2850 ?

Sébastien

 Commentaires   
Commentaire de Jérémie Bennejean [ 10/févr./06 12:09 ]
Imossible de mettre 4 cpu sur un chassis de 2850.
Par contre c'est possible de mettre 2 proc bi-core.
J'ai demandé a DELL de savoir si on peut intervertir 2 xeon mon core avec 2 xeon bi-core, j'attends une réponse.
Devis 2850 bi-core fait et donné
Commentaire de Jérémie Bennejean [ 14/févr./06 11:17 ]
Contact du support dell a ce sujet.
J'aurai la réponse d'ici demain.
Les points soulevé sont : peut - on intervertir des xeon mono-core avec des xeon bi-core .
Le socket est il le meme. le voltage aussi?
Le ventilateur ?
la comptabilité de la carte mere ?
Commentaire de Jérémie Bennejean [ 14/févr./06 13:52 ]
Monsieur bennejean,

La cartemere que vous avez sur la machine est compatible avec les processeurs Xeon dual core (Paxville).

Par contre le nouveau Xeon (paxville)a un radiateur qui est plus gros que sur les anciens Xeon , ce n'est pas le même modèle.



De plus, une mise à jour du bios sera éventuellement nécessaire pour prendre en compte le dual core .




Bonne journée

_____________________________________________
From: Roux, Yannick
Sent: Tuesday, February 14, 2006 11:26 AM
To: 'jeremie.bennejean@priceminister.com'
Subject: Information sur cartemere pe2850 -4SSG12J- case 512971208
Commentaire de Jérémie Bennejean [ 15/févr./06 15:43 ]
j'ai demandé une devis au commercial DELL pour intervertir les 2 procs.
Commentaire de Jérémie Bennejean [ 17/févr./06 11:04 ]
Intervertir 2 proc monocore avec des bicores est donc possible.
Il faut intervertir les ventilateurs en meme temps du fait qu'il soit differents.

Je ferme le jira du fait que l'achat de bicore n'est à l'ordre du jour.




[BIN-243] extraction mails pros auto pour envoi news pro Création: 11/déc./06 16:00  Mise à jour: 14/sept./07 17:33  Echéance: 13/déc./06 00:00  Résolue: 12/déc./06 16:07

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Bloquant
Rapporteur: Lorenzo Nuccio Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures

Pays:
FRA - France

 Description   
Hello Agathe,

Je dois envoyer une news pro cette semaine, j'aurai donc besoin, comme les mois précédents, d'une extract des mails pros auto pour pouvoir faire mon envoi sur EMV.

Deadline : mercredi soir.

Merci !

 Commentaires   
Commentaire de Agathe Remy [ 11/déc./06 17:32 ]
François,

Peux-tu voir si tu peux faire un rapport BI pour cet extract:-) Ainsi Lorenzo pourrait le rafraîchier quand il en a besoin.

Merci:-)

Agathe
Commentaire de François Le Lay [ 12/déc./06 16:07 ]
Le rapport est mis en place dans BI.




[APP-15282] Affiliation Programme Vendeur :: Metatache Création: 23/févr./07 13:54  Mise à jour: 25/oct./07 14:33  Résolue: 27/juil./07 17:47

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation
Affecte la/les version(s): ToDo
Version(s) corrigée(s): 17.0.0

Type: Nouvelle fonctionnalité Priorité: Mineur
Rapporteur: Richard Dubois Attribution: Agathe Remy
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: Microsoft Word Brief_Affiliation_Programme_Vendeurv1.doc     Microsoft Word specs_affiliation_vendeur.doc    
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-15283 Création d'un état BI pour le suivi d... Sous-tâche Fermé Romain Czornomaz  
APP-15295 Création du rapport des ventes Sous-tâche Fermé Romain Czornomaz  
APP-15296 Création de l'évènement "Activate sel... Sub-improvement Fermé Alexandre Garnier  
APP-15298 Poser les tags des plateformes Sous-tâche Fermé Olga Costa  
APP-15369 Clef cryptée des n°annonce Sous-tâche Fermé Swan Desportes  
APP-15870 Expiration : fonctionnement précis Sous-tâche Fermé Richard Dubois  
APP-16186 [affiliation vendeur] Développement Sub-new feature Fermé Olivier Bourgeois  
Pays:
FRA - France
Projets PM: *** RESERVE ***

 Commentaires   
Commentaire de Quentin de Chivré [ 04/juil./07 17:38 ]
A fermer ?
Commentaire de Ghislain Gridel [ 04/juil./07 17:53 ]
Les rapports BI sont prévus pour le 10 juillet.

Ghislain
Commentaire de Emeric Teil [ 04/juil./07 18:03 ]
De notre côté, tout est OK. On passe donc la main au BI pour la fin de suivi de cette méta-tache.




[BIN-658] [Avis] : Extract Inscrit au jeu concours avis Création: 01/mars/10 18:14  Mise à jour: 14/oct./10 15:37  Résolue: 02/mars/10 16:51

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Carole Visser Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel EXTRACT_REVIEW_GAME_0210.xlsx     File RE Impacts Flux 1M CTN-O.msg     Text File req_extract_review_game.sql    
Liens des demandes:
Duplicate
a pour doublon BIN-659 [Marketing] Données flux 1000Mercis Fermé
Similaire
similaire à APP-28871 Liste participants jeu concours avis Fermé
Pays:
FRA - France

 Description   
Bonjour,

Pour le moment, 1000Mercis ne dispose pas des données concernant l'inscription au jeu concours permanent avis.

Je dois cependant envoyer un email annonçant aux participants qu'ils n'ont pas gagné au jeu ce mois-ci.

Serait -il possible de réaliser un extract des PriceMembers inscrits au jeu concours au mois de février.

La newsletter devait être envoyée le 04/03.

Quand pensez vous pouvoir me fournir l'extract?

Merci d'avance

Carole




 Commentaires   
Commentaire de Dalila Belkebir [ 02/mars/10 13:27 ]
Julien,

Peux-tu regarder cela ASAP pour Carole ?
 
Merci.

Cdlt,
Dalila.
Commentaire de Carole Visser [ 02/mars/10 15:23 ]
Julien,

Est ce que tu penses pouvoir m'envoyer l'extract pour demain midi?

Si non, je reporte l'envoi de la news.

Merci

Carole
Commentaire de Julien Girardet [ 02/mars/10 16:51 ]
Comme vu avec Carole :

- Les données d'inscriptions au jeu concours Avis n'étaient pas pévu dans le périmètre de maj des flux 1M Impacts CTN-0 (voir mail MKT en pj)
- En pj l'extract des Users concernés par le tirage au sort du mois de Fevrier (j'ai vu les conditions du tirage au sort avec Renaud)

A voir comment on procède pour les prochains mois.
(L'ajout du "IS_REVIEW_GAME_PLAYER" dans le flux 1M n'est pas suffisant pour que 1M détermine si le User est concerné par le tirage au sort...)

Julien.
Commentaire de Carole Visser [ 22/mars/10 12:20 ]
Bonjour,

Avez-vous pu avancer sur le sujet?

Merci d'avance,

Carole
Commentaire de Julien Girardet [ 22/mars/10 16:25 ]
Bonjour,

Si le mail doit être envoyé à tous les users concernés par le tirage au sort, alors la cible doit être calculée en synchro avec le tirage au sort.
En effet, le tirage au sort prend en compte tous les users ayant déposés des avis dans le cadre du jeu ET étant inscrit au moment du tirage.
Donc l'état d'inscription au jeu concours à l'instant t est important pour déterminer la cible.

Si l'on veut envoyer les infos nécessaires à 1 M pour qu'il puisse déterminer la cible, il faudrait envoyer l'état d'inscription des users au jeu ainsi que les données concernant les avis déposés dans le cadre du jeu.
De plus, il y a peu de chance que 1M génère la cible le même jour que le tirage au sort. Donc il y aura forcément un décalage...

Donc je vois 2 solutions :
- On intègre la génération de la cible au process du tirage au sort (A voir avec les Devs). La cible étant la meme que le tirage au sort.
- On créée un rapport BI générant la cible (afin d'être envoyé à 1M) qui devra être lancé le même jour que le tirage au sort. Sachant que cette solution implique un cout niveau BI, car nous n'avons pas actuellement ces données dans notre DataWareHouse

A votre dispo pour plus d'infos.

Merci

Julien.
Commentaire de Agathe Remy [ 24/mars/10 15:20 ]
Carole,

Pour avoir la liste des participants au jeu concours avis du mois M-1 au moment du tirage au sort depuis le BO, ça nous demande un peu de DEV. Est-ce que tu peux nous faire un JIRA à dispatcher-CTN qu'on traitera en réserve dès qu'un DEV aura de la dispo ?

En attendant, tu pourras te baser sur l'équipe BI qui effectuera la requête à la mano (à faire en même temps que le tirage au sort pour être concordant).

Agathe, je te mets en observatrice du JIRA pour que tu puisse nous transmettre la requête que vous avez déjà construite.

Merci.

Fabrice FEUGAS
Commentaire de Agathe Remy [ 14/oct./10 15:37 ]
L'extract est à présent disponible en BackOffice : cf JIRA APP-28871

Agathe




[BIN-677] TFV: SLTV par tracking de 1ère mev Création: 21/mai/10 14:32  Mise à jour: 08/nov./10 11:48  Résolue: 14/oct./10 15:38

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Audrey Angleys Attribution: Valéria Gusa
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word DMR -Seller lifetime by first advert tracking 10.docx     Microsoft Word DMR -Seller lifetime by first advert tracking 11.docx    
Pays:
FRA - France

 Description   
Bonjour,

Comme discuté, nous aurions besoin de développer un rapport "SLTV par tracking de 1ère mev".

* Contexte:
Recrutement des vendeurs en décroissance : -3% en avril 2010.
On cherche donc à comprendre d'où provient cette décroissance, et à trouver quels canaux nous permettent de recruter de nouveaux vendeurs à fort potentiel.

* Objectif:
Piloter au mieux le budget vente en ayant connaissance de la valeur de nos vendeurs recrutés par canal d'acquisition.

Au bout de combien de temps nos vendeurs transforment-ils leur mev en vente effective selon les différents canaux d'acquisition? Y a-t-il des différences importantes de taux de transfo selon les canaux ? Et surtout, combien nous rapporte un vendeur recruté via tel canal ?

* Données à suivre dans le rapport :
¿ Mois de dépôt de la 1ère annonce (promo) [filtre]
¿ Mois considéré (activity month) [filtre]
¿ Groupe de tracking [filtre]
¿ Code de tracking [filtre]
¿ Nb de 1ères mev
¿ Nb de mev
¿ Nb de ventes effectives réalisées entre le mois de dépôt de la 1ère annonce et le mois considéré
¿ Somme de la com générée par les ventes effectives en question
¿ Taux de transfo : nb ventes effectives / (nb PMEV + nb MEV) => facultatif car je peux le calculer ensuite
¿ Valeur vendeur par tracking : Somme de la com/nb nouveaux vendeurs recrutés => facultatif car je peux le calculer ensuite

Je reste à votre dispo pour en parler de vive voix.

Merci d'avance!

Audrey


 Commentaires   
Commentaire de Agathe Remy [ 22/sept./10 10:28 ]
Bonjour Audrey,

Tu trouveras ci-joint les spécifications du rapport "SLTV by first advert tracking".
Stp, peux-tu les valider d'ici le 27/09 afin que nous puissions lancer les dévs la semaine prochaine?

Avec mes remerciements,
Agathe
Commentaire de Agathe Remy [ 22/sept./10 10:33 ]
Pour compléter la validation des spécifications, j'aurais quelques questions :
- faut-il ajouter le filtrage "tracking 30j"?, i.e. veux-tu que nous filtrions uniquement les promotions ayant déposé leur première annonce dans les 30 jours suivant le dépôt du coockie ?
- Veux-tu qu'on ajoute un indicateur "délai moyen de vente" afin de répondre à ta question "Au bout de combien de temps nos vendeurs transforment-ils leur mev en vente effective selon les différents canaux d'acquisition?"?
 - Veux-tu nous fournir une liste des groupes de tracking pour lesquels tu voudrais l'historique?

A ta dispo,
Agathe
Commentaire de Audrey Angleys [ 23/sept./10 18:16 ]
Bonjour Agathe,

Comme vu ensemble cet après-midi:

- Oui pour le tracking 30j

- Oui également pour rajouter le délai moyen de vente (merci!)

- Pour les paramètres de dates, le but est d'établir un suivi (voir comment évolue la part des différents canaux) donc il faudrait en filtre le mois d'activité et que le rapport puisse sortir les actions de toutes les promos de vendeurs dans le mois.

- Liste des groupes de trackings pour l'historique:
=> CRM Vente
=> priceletter-vente
=> Test Vente
=> LS-Google (un seul tracking nous intéresse dans celui là: LS-Google-sell)
=> Zanoxx (le tracking qui nous intéresse : Zanoxx-CarrefourInternet)
=> Affiliationx - Vendeur (celui qui nous intéresse: Affiliationx-Programme-Vendeur)

Merci d'avance!

A ta dispo pour en reparler,

Audrey
Commentaire de Agathe Remy [ 29/sept./10 17:42 ]
Corrections suite à la validation d'Audrey.

Agathe
Commentaire de Audrey Angleys [ 05/oct./10 15:55 ]
Hello,

Juste pour info, pour quand prévoyez-vous la livraison de ce rapport?

Merci !

Audrey
Commentaire de Valéria Gusa [ 05/oct./10 16:05 ]
Bonjour,

Normalement, c'est prévu courant semaine prochaine.

Valeria
Commentaire de Audrey Angleys [ 05/oct./10 16:09 ]
OK merci!
Commentaire de Valéria Gusa [ 14/oct./10 15:38 ]
Bonjour,
 
Le rapport 'Seller lifetime value by first advert tracking' vient d'être livré en Production sur les plateformes FR, ES et UK (Dossier Seller).
Merci de valider la fiche Jira afin que nous pussions la fermer.


Valeria.
Commentaire de Valéria Gusa [ 14/oct./10 16:00 ]
L'historique, pour les groupes de tracking demandés, est disponible dans le dossier suivant :

T:\BI\02 - Historiques de données\2010-10 Seller lifetime value by first advert tracking

Valeria
Commentaire de Audrey Angleys [ 26/oct./10 16:21 ]
Hello,

Pour l'historique des données, serait-il possible de le ressortir pour ce tracking "Affiliationx-EmaileurVendeurs" (dans le groupe de tracking "Affiliationx") svp ?

Merci d'avance et désolée pour le contretemps.

Audrey
Commentaire de Valéria Gusa [ 26/oct./10 17:11 ]
Salut,

L'historique demandé a été généré dans le dossier T:\BI\02 - Historiques de données\2010-10 Seller lifetime value by first advert tracking

Valeria
Commentaire de Audrey Angleys [ 26/oct./10 17:42 ]
Merci beaucoup!




[BIN-561] [1Euro] : Ecart sur commission 1Euro.com Création: 26/févr./09 10:13  Mise à jour: 18/nov./10 18:07

Etat: Ouvert
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Charlotte Fachan Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Salut Agathe,

comme convenu ensemble ci joint un petit topo sur le rapport qu'il me faudrait pour vérifier l'écart sur le commissionnement 1.com

Chaque mois, 1¿.com nous transmet des infos sur le nombre de souscription au service générée par PriceMinister.
Comme tu le sais nous sommes rémunérés 12¿ sur chaque nouveau clients apportés.
J'ai cependant noté de gros écarts avec ce que nous facturons à 1¿.com (entre 17 et 20%)

Il me faudrait donc un rapport sur le nombre de transactions par mois payées avec 1¿.com (pour la première fois) et le nombre de celles qui ont été annulées (de quelques manières que ce soit et qui n'ont pas donné lieu à une souscription)
L'idéal serait d'avoir l'info par mois et sur 2007 et 2008 pour pouvoir comparer avec les données que j'ai de mon côté.

Pour ton aide tu trouveras sous mon public les bilan 1¿ (onglet souscription)

A ta dispo pour en parler

Merci

Charlotte

 Commentaires   
Commentaire de Charlotte Fachan [ 04/mars/09 09:10 ]
Salut Agathe

je reviens vers toi concernant cette demande.
As tu besoin de plus d'infos là dessus pour avancer?

A ta dispo pour en parler

Merci

Charlotte
Commentaire de Agathe Remy [ 04/mars/09 11:11 ]
Bonjour Charlotte,

Au cours de notre point bi-mensuel de lundi avec Odile et Thomas, ce JIRA a été défini en priorité 5. Il ne sera donc pas traité avant avril et nous reviendrons vers toi lorsque nous le traiterons.
Je crois d'ailleurs qu'Odile voulait en discuter avec toi avant...

Agathe
Commentaire de Thomas Beylot [ 10/mars/09 16:24 ]
Hello

en fait la conclusion du point bi-mensuel était plutôt que je regardais la demande de Charlotte afin de savoir si on pouvait le faire nous même. Si c'est le cas, pas de charge pour vous, sinon, on revient (avec odile) vers vous pour prioriser. Ce n'est pas tout à fait la même chose :)

bref
mais j'ai l'impression qu'on peut s'en sortir sans vous.

Il suffit de se construire un rapport "transactions avec mode de paiement 1¿", plus statut du panier (cancelled etc)

non ?


thomas
Commentaire de Agathe Remy [ 10/sept./09 14:44 ]
Bonjour Thomas,

Des nouvelles de ce JIRA? Puis-je le clôturer?

Merci:-)
Agathe
Commentaire de Dalila Belkebir [ 04/janv./10 09:58 ]
Bonjour Thomas,

Des nouvelles de ce JIRA?
Le besoin sera-t-il repris dans le projet libéralisation 1¿.com ?

Puis-je le clôturer?

Merci.

Dalila.




[CAT-3032] OP de collecte 2010 - import de contacts Création: 16/août/10 15:23  Mise à jour: 08/déc./10 10:05  Résolue: 08/déc./10 10:05

Etat: Résolu
Projet: Paramétrage - Non Import
Composants: Import de contacts Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Carole Visser Attribution: Carole Boucheny
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Codes_provenance_PM.xlsx     Microsoft Excel Codes_provenance_PM2.xlsx     Microsoft Excel Nouveaux_Contacts_Affiliation_18102010.xlsx     File resultat_18-10-2010.csv    
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
CAT-3252 Désabonnement de tous les contacts Sub-bug Résolu Carole Boucheny  
CAT-3256 Problème avec l'import de contact Sub-bug Résolu Carole Boucheny  
Pays:
FRA - France

 Description   
Bonjour,

Comme chaque année, nous allons mettre en place mi-septembre une nouvelle opération de collecte d'adresses. Jusqu'à présent, ce type d'opérations était réalisé avec 1000Mercis. Nous avons choisi cette année de faire appel à une nouvelle agence La Fabrique à Jeux.

Cependant, contrairement à 1000Mercis, cette nouvelle agence ne dispose pas de notre base de données et ne pourra donc pas réaliser seule la déduplication. Cela pose un problème au niveau du suivi de l'opération et au niveau de l'affiliation.

Pour remédier à ce problème, l'agence nous fournira chaque semaine la liste des inscrits à l'opération. Nous devrons donc effectuer la déduplication avec notre base avant de les intégrer.
Je pourrais dans ce cas renvoyer à l'agence et à la plateforme d'affiliation la liste des adresses non présentes dans notre base en fonction d' idfrom.

A votre dispo pour toute question complémentaire,

Carole


 Commentaires   
Commentaire de Fotigui Tangara [ 16/août/10 15:30 ]
Demande destinée plutôt au pôle CAT ?
Commentaire de Jérôme Viviès [ 20/août/10 10:22 ]
Carole (V), et Clémence,
Petite remarque en passant : tous les jiras que vous ouvrez au param doivent être des JIRAs "Param non import" (CAT) - les jiras "Param import" (IMP) sont destinés à l'équipe qui s'occupe de l'importation des fichiers de stocks des vendeurs pro - rien à voir.
Et il faut systématiquement mettre Carole Boucheny en observatrice des demandes flux / import de contacts - je ne sais pas si le mot est bien passé.
M E R C I D E T R A N S M E T T R E A V O S C O L L E G U E S :)))))
Commentaire de Carole Boucheny [ 09/sept./10 16:44 ]
Bonjour,

Voici les informations sur le ftp à transmettre au partenaire :
Host : ftp.priceminister.com
Login : market
Password :m!2010PM

Le partenaire devra donc déposer ses fichiers à la racine.

Carole, peux-tu me confirmer la structure qu'auront les fichiers fournis.

Merci
Commentaire de Carole Boucheny [ 10/sept./10 17:08 ]
Le script de mapping a été adapté sur hercule "market.pl".

Carole peux-tu aussi m'envoyer les correspondances entre les idfrom et les codes tracking.

Merci
Commentaire de Carole Boucheny [ 10/sept./10 17:14 ]
(Adaptation du script market.sh)
Commentaire de Carole Boucheny [ 14/sept./10 15:34 ]
Les fichiers seront déposé à la racine.

Les extracts seront au format csv avec des « ; » comme séparateur.

L’ordre des champs :
Email ; nom ; prénom ; civilité ; idfrom ; optin
Commentaire de Carole Visser [ 14/sept./10 17:19 ]
En PJ le tableau de correspondance qui sera complété au fur et à mesure
Commentaire de Carole Visser [ 14/sept./10 17:29 ]
Il y avait une erreur dans le premier fichier.
Il faut utiliser le PM2
Commentaire de Carole Boucheny [ 27/sept./10 11:43 ]
Bonjour,

J'ai mis en place les mapping avec le tableau fourni.
Quel est le code tracking par défaut pour les cas qui n'ont pas encore été défini ?

Merci
Commentaire de Carole Boucheny [ 04/oct./10 10:54 ]
Bonjour,

Je n'ai pas de nouvelle pour cette demande.

Pouvez-vous me fournir un code tracking par défaut ?
Avez-vous déjà reçu un fichier d'import de contact à faire ?

Merci
Commentaire de Carole Visser [ 04/oct./10 12:32 ]
Bonjour Carole,

Si je comprends bien ta demande, il y aurait des nouveaux contacts sans code de provenance.

Ce n'est pas normal. Combien d'individus cela représente t-il?

Merci

Carole

Commentaire de Carole Boucheny [ 04/oct./10 13:54 ]
Salut,

Je n'avais pas vu que deux fichiers ont déjà été déposé. Ce que je disais pour les codes tracking c'est qu'il est bien de mettre un code par défaut au cas où le code de provenance n'aurait pas été prévu.

Merci
Commentaire de Carole Visser [ 04/oct./10 15:46 ]
Carole,

Voici le first tracking à utiliser pour les individus dont le code de provenance n'est pas défini : 2317440

Comme vu ensemble, il faudrait compléter les fichiers d'extract en indiquant pour chaque individu s'il était déjà présent dans la base PM ou non.

A ta dispo si tu as des questions.

Carole
Commentaire de Carole Boucheny [ 04/oct./10 16:31 ]
J'ai mis le code tracking par défaut.

Par contre, j'ai regardé de plus près pour savoir si chaque individu était nouveau ou non. Je ne peux pas avoir cette information. Les logs du batch d'import n'étant pas assez détaillé. Je ne peux que faire un comptage.

L'autre solution serait d'extraire de la base (par requête sql) les emails des contacts avec les codes first tracking listé. Ceci veut dire qu'on ne listera que les nouveaux conctacts avec leur provenance. Est-ce que cette solution pourrait aller ?

Merci
Carole
Commentaire de Carole Visser [ 05/oct./10 17:15 ]
Carole,

Comme vu ensemble, ok pour la deuxième solution.

Il faudrait que tu m'envoies chaque semaine la liste des nouveaux contacts avec leur first tracking et leur adresse email.

Pour le moment, il y a un problème avec les fichiers présents sur le ftp. Je te fais signe dès que c'est résolu.

Carole
Commentaire de Carole Visser [ 06/oct./10 10:29 ]
Bonjour Carole,

Tu peux maintenant utiliser le nouvel fichier déposé par La Fabrique à Jeux sur le ftp (celui du 05/10).

Ce fichier regroupe les 2 précédents ainsi que les individus manquants.

A ta dispo si tu as des questions,

Carole
Commentaire de Carole Visser [ 08/oct./10 11:17 ]
Bonjour Carole,

As tu pu avancer sur l'intégration et la dédup des premiers extract?

Merci

Carole
Commentaire de Carole Visser [ 14/oct./10 11:59 ]
Carole, je n'ai pas eu de retour de ta part à ce sujet.

Commentaire de Carole Boucheny [ 15/oct./10 17:10 ]
Carole,

Peux-tu me confirmer que pour les provenances à partir de "PRMI015" suivantes le code tracking est vide ou est-ce que je dois mettre le code tracking par défaut (2317440 ) ?

Merci
Carole
Commentaire de Carole Visser [ 15/oct./10 17:16 ]
Carole,

Normalement tu dois avoir très peu de provenances "PRMI015", moins de 5. Si ce n'est pas le cas, c'est qu'il y a un problème.
Pour ce code de provenance, il faut utiliser le code de tracking : 2314243

Merci

Carole
Commentaire de Carole Boucheny [ 15/oct./10 17:38 ]
Oui, il n'y en a pas beaucoup mais j'avais un doute car à partir de PRMI015 il n'y a pas de valeur correspondante. Est-ce que pour les suivantes c'est aussi 2314243 ? Dans ce cas, peux-tu mettre à jour le fichier joint.

Par contre, il y en a beaucoup plus de provenance "MSPONR". Pour celle-ci j'utilise aussi le code de tracking par défaut ?

Merci
Commentaire de Carole Visser [ 15/oct./10 17:47 ]
Pour le code de provenance MSPONR, il faut utilisé le code de tracking 2314242
Normalement, il ne doit pas y avoir d'individu avec des codes de provenance supérieur à PRMI015
Commentaire de Carole Boucheny [ 18/oct./10 16:42 ]
Le premier import a pu être lancé.

Demain, nous pourrons donc connaître les nouveaux contacts. Comme vu ensemble :
_ créer un fichier csv avec les informations suivantes pour les nouveaux contacts : id, mail, code tracking
_ il faut créer un ftp pour que les affiliés puissent récupérer ces fichiers.
Commentaire de Carole Visser [ 18/oct./10 16:54 ]
Il s'agit du code de provenance et non du code de tracking. Le code de provenance est présent dans l'extract fourni par la fabrique à jeux.
C'est la même chose pour l'id, il est présent dans l'extract.

Est ce que tu pourrais m'envoyer le fichier avec l'ensemble des nouveaux contacts et ne déposer sur le nouveau ftp que les contacts avec les codes de provenance PRMI011 et PRMI012?

Merci

Carole
Commentaire de Carole Boucheny [ 18/oct./10 16:55 ]
J'ai créer le compte ftp suivant :
login : market_affiliation
mdp : market!AffiliationPM
Commentaire de Carole Boucheny [ 18/oct./10 16:57 ]
(Le Host est toujours ftp.priceminister.com)
Commentaire de Carole Boucheny [ 18/oct./10 17:07 ]
Ok c'est noté. Je pourrais t'envoyer cela demain matin. (Attention ceci sera pour le fichier du 05).
Demain je ferais l'import pour le 11 et du 18. Donc Mercredi nous serons à jour.

Les semaines suivantes, je ferais l'import tous les lundis. Tu auras donc le fichiers des nouveaux contacts le mercredi.
Commentaire de Carole Visser [ 18/oct./10 17:10 ]
Il me le faudrait vraiment sur le dernier import car c'est celui qui contient les donner sur l'affiliation.
Il regroupe tous les inscrits depuis le début du jeu, ça ne sert à rien de le faire sur les 3.
Commentaire de Carole Boucheny [ 19/oct./10 10:07 ]
Bonjour,

Si j'importe uniquement le fichier du 18 c'est bon, c'est cela ??

Merci
Carole
Commentaire de Carole Visser [ 19/oct./10 10:14 ]
Oui c'est ça.
Il regroupe l'ensemble des inscrits depuis le début du jeu
Commentaire de Carole Boucheny [ 19/oct./10 13:34 ]
Le batch d'import de contact lancé hier par l'exploit a généré des erreurs. Je dois donc regarder ce qui provoque cela et le corriger avant de pouvoir importer les contacts de lundi.

Je te tiens au courant et règle ce problème au plus vite pour qu'on puisse avoir la liste des nouveaux contacts au plus tard demain.

Merci
Carole
Commentaire de Carole Boucheny [ 19/oct./10 13:50 ]
Le problème est résolu. L'exploit relancera le batch dans l'après-midi.
Commentaire de Carole Visser [ 20/oct./10 14:12 ]
Bonjour Carole,

Où en es tu avec la dédup des inscrits à l'OP de collecte?
Il faut absolument que je fournisse les chiffres à la plateforme d'affiliation aujourd'hui.

Merci

Carole
Commentaire de Carole Boucheny [ 20/oct./10 14:16 ]
L'exploit n'a pas pu lancer le batch ce matin, ils l'ont lancé aujourd'hui. Du coup, les dba sont en train d'exécuter la requête que je leur ai donné directement en prod. Tu auras le fichier aujourd'hui.
Commentaire de Carole Boucheny [ 20/oct./10 15:32 ]
Ci-joint le fichier avec l'email, le code de provenance et l'id.
Je l'ai aussi déposé sur le ftp market_affiliation.
Commentaire de Carole Visser [ 21/oct./10 11:10 ]
Merci Carole.

Sur le ftp market_affiliation, il fallait déposer un fichier avec uniquement les nouveaux contacts avec les codes de provenance PRMI011 et PRMI012.
Commentaire de Carole Visser [ 21/oct./10 11:13 ]
Carole,

Tu trouveras en pièce jointe le nouveau fichier avec seulement les codes de provenance PRMI011 et PRMI012 à déposer dès que possible sur le ftp market_affiliation.

Merci

Carole
Commentaire de Carole Visser [ 21/oct./10 11:16 ]
Carole,

Dis moi dès que c'est fait pour que je prévienne la plateforme d'affiliation.

Merci
Commentaire de Carole Visser [ 21/oct./10 11:43 ]
Je suis désolée de te relancer mais il faut vraiment que ce fichier soit sur le ftp avant midi.

Merci

carole
Commentaire de Carole Boucheny [ 21/oct./10 12:08 ]
Le fichier est déposé sur le ftp
Commentaire de Carole Boucheny [ 25/oct./10 10:44 ]
Bonjour,

J'ai récupéré le fichier de ce matin. Le batch sera lancé par l'exploit dans la journée. Nous pourrons donc avoir les résultats des nouveaux inscrits demain matin.

Carole
Commentaire de Carole Visser [ 26/oct./10 17:50 ]
Carole,

La fabrique à jeux vient de déposer un nouveau fichier sur le ftp en ajoutant une colonne partenaire.

Pour être plus clair, il y a 2 choix pour la colonne "'optin"
Non: Optout
Oui : Optin PriceMinister

Pour la colonne "partenaire", 2 choix:
Non: Pas optin partenaire
Oui : Optin partenaire

Comme vu ensemble, il faut donc mettre à jour ces infos pour les nouveaux contacts et les inscrits déjà en base.

Pour les inscrits déjà en base, il ne soit s'agir que d'upgrade, c'est à dire que si la personne est optin partenaire en base et a coché seulement optin dans le jeu, on conserve le statut d'optin partenaire.

A ta dispo si tu as des questions.

carole
Commentaire de Carole Visser [ 26/oct./10 19:09 ]
Carole,

Comme vu ensemble, est ce que tu pourrais modifier le fichier déposé sur le ftp destiné à la plateforme d'affiliation en supprimant les individus qui ne sont pas optin?

Merci

Carole
Commentaire de Carole Visser [ 27/oct./10 11:26 ]
Bonjour Carole,

Est ce que tu as pu avancer sur le nouveau fichier pour la plateforme d'affiliation?
J'ai vraiment besoin de ce fichier rapidement pour prendre des décisions sur la suite de la campagne.

Merci

Carole
Commentaire de Carole Boucheny [ 27/oct./10 14:05 ]
Salut Carole,

Le fait que le partenaire n'ai pas fourni dès le départ un fichier dans un format correspondant au formulaire du jeu nous a induit en erreur et les imports de contacts se sont mal faits.

Voici le mail envoyé aux équipes techniques afin de rechercher une solution à ce problème :

Bonjour,

Suite au "Grand jeu concours" (opé "collecte"), plusieurs imports de contacts ont eu lieu sur le site France (https://priceminister.onjira.com/browse/CAT-3032).
Cependant, à cause d'une mauvaise compréhension avec le partenaire qui nous fournit les fichiers, les abonnements aux newsletters ne sont pas corrects.
Des gens ont donc été abonnés par erreur aux newsletters PM ou PM + partenaires.

Nous devons trouver rapidement une solution afin de corriger la situation.

=> Merci de regarder ce qui est proposé plus bas et de donner votre avis.


1/ ANALYSE DU PROBLEME

Jusqu'à présent le partenaire remplissait une colonne par Oui ou Non. Cette colonne était interprétée comme cela de notre côté :
Si Oui --> Abonnement aux newletters Price et Partenaire
Si Non --> Abonnement aux newletters Price

La colonne Oui et Non actuelle correspond en fait à :
Oui --> Abonnement aux newletters Price
Non --> Aucun abonnement

Nous avons donc abonnement :
- de personnes à la NL PM, alors qu'elles n'auraient pas dû l'être.
- de personnes à la NL PM + partenaires alors qu'elles auraient dû être abonnées seulement à la NL PM.

De plus, nous avons en fait 3 cas d'abonnements possibles dans ce jeu :
- Abonnement aux newletters Price
- Abonnement aux newletters Price et Partenaire
- Aucun abonnement


2/ SOLUTION


- COTE PRICE

=> Le partenaire doit nous refournir l'ensemble des contacts à importer, avec une nouvelle colonne pour les Abonnements Partenaire

=> Avant cela, il faudrait pouvoir désabonner tous les contacts qui ont été créés par ce jeux.

Voici les actions qui permettraient de remettre le maximum de choses à plat.
A --> Supprimer tous les contacts de la table temporaire de mise à jour de contact (seul le batch d'import de nouveau contact a tourné).
B --> Supprimer les contacts qui n'ont pas encore donné lieu à création de compte.
C --> Désabonner les contacts qui se sont créés un compte.

Implémentation :

A --> requête sur la base
B --> ? difficile à faire en SQL ? - Utiliser une moulinette qui simulerait le clic sur le bouton "Fermeture" du compte (en BO) ?
C--> Idem _ Utiliser la même moulinette mais avec l'url du bouton "Tout désabonner".
Ces deux dernières actions envoient un mail au contact.
Il faudrait donc modifier l'adresse email avant de le faire.
Ceci ne pose pas de problème lorsque les comptes seront fermés.
Par contre c'est plus délicat lorsque pour désabonner tous les contacts qui ont un compte Price.

Tout le monde est-il d'accord avec cette analyse ou qqn voit-il une autre façon de faire ?
Qui fabriquerait / validerait les moulinettes ?


- COTE PARTENAIRES

Il va falloir désabonner les contacts qui ont été transmis dans le cadre de cette opé.

=> Même procédure que pour l'incident précédent...


Merci pour votre retour rapide.
Commentaire de Carole Visser [ 28/oct./10 10:08 ]
Bonjour Carole,

Comme vu avec toi hier, je souhaite apporter une petite précision concernant le nouveau fichier d'import.
Les colonnes optin et partenaire sont remplies par la fabrique à jeux de façon binaire en fonction de si la personne à cocher une case ou non.
Dans le fichier, on observe pour de nombreux individus "non" dans la colonne optin et "oui" dans la colonne partenaire. Pour ces individus, il faut considérer qu'ils sont optin PriceMinister même s'il est mentionné que non car le "oui" dans la colonne partenaire signifie qu'il souhaite recevoir les offres de PriceMinister et de ses partenaires.

A ta dispo si tu as des questions,

Carole
Commentaire de Carole Boucheny [ 29/oct./10 09:40 ]
Salut,

Je vais relancer l'import de contact. Avant cela je veux valider une dernière fois avec toi les abonnements.
En gros, on a 3 cas : Optin Price, Optin Partenaire, Pas d'Optin.

Dans le cas Optin Price, on abonne aux newletters :
- HighTech
- Culturelle
- Mode
- Maison
- Auto

Si Optin Partenaire :
- HighTech
- Culturelle
- Mode
- Maison
- Auto
- Partenaire

Si pas d'Optin :
Aucun abonnement.

Merci
Carole
Commentaire de Carole Visser [ 29/oct./10 14:21 ]
C'est ça!
Commentaire de Carole Visser [ 02/nov./10 16:29 ]
Carole,

Je sais qu'il y a encore des problèmes avec les groupes d'abonnement mais il faudrait vraiment régler ça rapidement. On ne peut pas se permettre d'envoyer des news aux personnes qui ont déclaré ne pas vouloir en recevoir.

Il faudrait également faire au plus vite la dédup du fichier que la fabrique à jeux a déposé hier sur le ftp.J'ai vraiment besoin de ces infos pour suivre la campagne d'affiliation.

Merci de revenir vers moi au plus vite à ce sujet et n'hésite pas à faire signe si tu as des questions.

Carole
Commentaire de Carole Boucheny [ 02/nov./10 17:09 ]
Salut,

Le problème n'est pas si simple que cela à régler et demande l'intervention de d'autres équipes.
Je travaille au maximum dessus pour te donner les éléments au plus vite.

Je te tiens au courant des avancements.

Carole
Commentaire de Carole Visser [ 03/nov./10 16:25 ]
Carole,

Où en es-tu au niveau de la modification des abonnements et de l'import des nouveaux contacts?

Peux-tu m'expliquer ce qui pose problème et quelles sont les équipes concernées afin que je comprenne un peu mieux d'où vient le blocage?

Il faut vraiment avancer au plus vite sur le sujet.

Merci

Carole
Commentaire de Carole Boucheny [ 03/nov./10 16:46 ]
Bonjour,

Pour résumer. Les contacts qui ont été créé vendredi 29 ont été abonnés aux newletters d'AVAL et de VMC. Demain, Patrick rentre de congé et pourra donc faire ces modifications dans notre base. Le BI pourra ensuite demander la mise à jour du côté d'AVAL et VMC.
(Ce problème est apparue car la colonne qui correspond à ces abonnements dans nos tables temporaires est vide. Or le batch d'import de contact gère mal les nulls et abonne aux newletters. J'ai créé un jira pour ce problème APP-31579). En attendant une correction, plusieurs actions ont été faites et j'ai modifié mes scripts pour que ces colonnes ne soient jamais vide mais à 0.
Les imports de contact normalement depuis ce matin. (Les batch tournent, on aura donc le comptage demain des nouveaux inscrits depuis le début). J'ai d'ailleurs été formée aujourd'hui, pour pouvoir lancer moi-même ces batchs (jusqu'à présent c'était l'exploit qui s'en occupait).

La situation est donc presque rétablie, puisqu'il manque juste la modification en base. Et tu auras le comptage demain.

Carole

Commentaire de Carole Boucheny [ 04/nov./10 16:25 ]
Pour faciliter la récupération des nouveaux contacts, j'ai créer le script "rapport-market.pl" sur hercule.
Je le lancerais donc le lendemain de chaque import de contact. Et déposerais le fichier généré sur le ftp pour l'affiliation.


Carole
Commentaire de Carole Boucheny [ 05/nov./10 14:56 ]
Pour info, les contacts qui avaient été inscrits à VMC et AVAL ont été désabonné dans notre base. Le BI envoi régulièrement les nouveaux et anciens inscrits aux newletters à AVAL et VMC. La mise à jour sera donc faite à ce moment là. (Il me semble que c'est le 10 de chaque mois).
Commentaire de Carole Boucheny [ 18/nov./10 12:05 ]
Le code tracking lorsque la personne n'a pas de code de provenance est 2317440.
Commentaire de Carole Boucheny [ 08/déc./10 10:05 ]
Le dernier import a eu lieu hier.




[APP-17500] [Oracle] #100 ORA-00001: unique constraint (PRODUCT_1.CHK_PRODUCT_ID_RANK) violated Création: 08/août/07 09:03  Mise à jour: 02/oct./07 16:25  Résolue: 19/sept./07 15:38

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 15.0.0
Version(s) corrigée(s): 17.0.0

Type: Bogue Priorité: Majeur
Rapporteur: Ange Ferrari Attribution: Manuel Sadok
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à APP-17538 [Oracle] Contrainte d'unicité 'PRODUC... Fermé
Pays:
FRA - France
Projets PM archivés: Maintenance 17.x.x

 Description   
Voila la stack trace

2007-08-07 21:11:43,279 INFO [Processor292] jacques47 - >>> POST http://www.priceminister.com/referential!action=tracklisti...&issubmi
t=true&popup=true&productid=56789975&submitbtn=Valider&title1-1=Mister Boo...&title1-2=Mopin'n Bi...&trackcount1=12
2007-08-07 21:11:43,279 INFO [Processor292] jacques47 - Same request - count=1 - delay=284ms
2007-08-07 21:11:43,447 WARN [Processor292] jacques47 - SQL Error: 1, SQLState: 23000
2007-08-07 21:11:43,447 ERROR [Processor292] jacques47 - [Oracle] #100 ORA-00001: unique constraint (PRODUCT_1.CHK_PRODUCT_ID_RANK) vio
lated

2007-08-07 21:11:43,447 ERROR [Processor292] jacques47 - Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: could not insert: [com.babelstore.stock.entity.PrdSpecification]
        at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:69)
        at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
        at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2077)
        at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2426)
        at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:51)
        at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
        at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296)
        at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
        at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:877)
        at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:201)
        at org.jboss.ejb3.entity.InjectedEntityManager.flush(InjectedEntityManager.java:122)
        at com.babelstore.stock.service.ProductManagerBean.flush(ProductManagerBean.java:1066)
        at sun.reflect.GeneratedMethodAccessor949.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:109)
        at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:32)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:113)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:138)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:32)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:163)
        at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:60)
        at $Proxy271.flush(Unknown Source)
        at com.babelstore.stock.service.SpecificationServiceBean.addTracklistingSpecifications(SpecificationServiceBean.java:135)
        at sun.reflect.GeneratedMethodAccessor1147.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:109)
        at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:32)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:113)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:138)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:32)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
        at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:163)
        at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:60)
        at $Proxy273.addTracklistingSpecifications(Unknown Source)
        at com.babelstore.referential.front.TracklistingViewAction.execute(TracklistingViewAction.java:263)
        at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:343)
        at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:299)
        at com.babelstore.util.web.Dispatcher.innerLoad(Dispatcher.java:212)
        at com.babelstore.util.web.Dispatcher.load(Dispatcher.java:185)
        at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:153)
        at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:115)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:138)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
        at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)


 Commentaires   
Commentaire de Manuel Sadok [ 19/sept./07 15:38 ]
La réponse est dans les logs :
"2007-08-07 21:11:43,279 INFO [Processor292] jacques47 - Same request - count=1 - delay=284ms "

La personne a validé le mm formulaire de soumission de tracklisting 2 fois dans la foulée.




[APP-7999] Fichiers non existants demandés sur le serveur Web (ErrorLog) Création: 16/mars/06 17:40  Mise à jour: 25/juin/07 18:36  Résolue: 20/mars/06 10:59

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 8.1.2
Version(s) corrigée(s): 8.1.2a

Type: Bogue Priorité: Majeur
Rapporteur: Antoine Koener Attribution: Andrei Matyas
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Site: Prod

 Description   
Analyse de error_log après la 812:
Error Apache:

Erreurs liées à la 812:

(première colonne f ou c, f pour file not found et c pour client denied by configuration)

~/bin/apache_error < error_log | sort -n -k 2 | grep V812
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-francemobiles/content/V812/front/brand/francemobiles/images/header/tab_over_home.gif
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/brand
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/auto
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/arrond-g.gif
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/header/logo.gif
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/header/tab_off
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/logo.gif
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/koobuycity/images/buY
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/virginmega/images/assistance/arrow/arrow_vehicle.gif
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_clothing.gif
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/box_checked_gray.gif
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/button/buy_clothing.gif
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/button/close.gif
f 1 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/barcode/barc
f 2 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/cd-occasion.gif
f 2 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/francemobiles/images/auto/footer
f 2 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_electronics.gif
f 2 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_music.gif
f 2 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_white.gif
f 3 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/camif/images/header/
f 3 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_books.gif
f 3 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_games.gif
f 3 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_sport.gif
f 4 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/epik/images/auto/img
f 4 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_computer.gif
f 5 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_baby.gif
f 5 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_music.gif
f 6 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/
f 6 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/button/alert.gif
f 7 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_video.gif
f 8 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_video.gif
f 8 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_baby.gif
f 8 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_books.gif
f 9 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_clothing.gif
f 10 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_electronics.gif
f 11 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/liberation/front
f 12 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_games.gif
f 17 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/assistance/arrow/arrow_hifi.gif
f 19 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_white.gif


f 21 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_hifi.gif
referer: http://www.priceminister.com/boutique/DORNETTE/category/160756
referer: http://www.priceminister.com/boutique/adnauto69

f 26 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/bullet/bullet_computer.gif
referer: http://bo.priceminister.com/boutique/TUNINGMANIA
referer: http://www.priceminister.com/boutique/wild78/type/1780
referer: http://www.priceminister.com/boutique/delux/type/1780


f 37 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/francemobiles/images/header/tab_over_home.gif
referer: http://francemobiles.priceminister.com/telephone-pda
referer: http://francemobiles.priceminister.com/navigation?action=se&ss=15&kw=3500+cliparts&category=search_computer
referer: http://francemobiles.priceminister.com/offer/buy/4723195/Samsung-SGH-E310-Telephone-cellulaire-avec-appareil-photo-numerique-GSM-Mobile.html


f 46 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/assistance/arrow/arrow_vehicle.gif
referer: http://bo.priceminister.com/boutique/TUNINGMANIA/type/1149
referer: http://www.priceminister.com/cart
referer: http://www.priceminister.com/offer?action=profile&sellerlogin=Acc-auto

f 46 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/wish/wish_promotion.gif


f 91 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/default/cover_carminister.gif
referer: http://www.priceminister.com/offer/vehicle/productid/18247845

f 105 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/images
referer: http://www.priceminister.com/assistance/1200

f 334 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/camif/front

f 2503 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/front
referer: http://www.priceminister.com/assistance


Les 30 erreurs les plus courantes
~/bin/apache_error < error_log | sort -n -k 2 | tail -30
f 98 /usr/local/apache/htdocs/pmweb/virtualhost-bo-jmh/visuels
f 101 /usr/local/apache/htdocs/pmweb/virtualhost-www/visuels/2006-02-10-auto/108x724-auto.jpg
f 110 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/images/auto/images
c 166 bargain
c 166 home
c 166 root_baby
c 166 root_books
c 166 root_clothing
c 166 root_electronics
c 166 root_games
c 166 root_music
c 166 root_sport
c 166 root_vehicle
c 166 root_video
c 166 root_white
c 166 root_wine
c 166 tab_600 <------------- Qu'est ce que c'est comme URL ?
c 166 tab_700 <--------------Même question
c 166 travel
f 190 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V7_2_4_a/front/brand/www/images/campaign
f 196 /usr/local/apache/htdocs/pmweb/virtualhost-img/visuels/2006-02-27-autopromo/160x90-discount.gif
f 241 /usr/local/apache/htdocs/pmweb/virtualhost-www/affiliation/visuels/coupon/paves_400x150
f 334 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/camif/front
f 402 /usr/local/apache/htdocs/pmweb/virtualhost-www/MSOffice
f 408 /usr/local/apache/htdocs/pmweb/virtualhost-www/_vti_bin
c 608 /usr/local/apache/htdocs/pmweb/virtualhost-bi/maintenance.asis
f 610 /usr/local/apache/htdocs/pmweb/virtualhost-bambinoccasion/maintenance.asis
f 2503 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V812/front/brand/www/front
c 2657 403.html
f 6634 /usr/local/apache/htdocs/pmweb/virtualhost-www/newsletter/2006-03-13-hitech57/spacer.gif
referer: http://webmail16f.wanadoo.fr/webmail/fr_FR/read.html?IDMSG=2086&FOLDER=SF_INBOX&ORIGIN=SYSTEM_FOLDER
Cette image est appelée par les tous les lecteurs de courrier en ligne ...


/usr/local/apache/htdocs/pmweb/virtualhost-www/newsletter/2006-03-13-hitech57/spacer.gif,



 Commentaires   
Commentaire de Swan Desportes [ 16/mars/06 18:25 ]
C'est quoi ce scandale !
f 6634 /usr/local/apache/htdocs/pmweb/virtualhost-www/newsletter/2006-03-13-hitech57/spacer.gif
referer: http://webmail16f.wanadoo.fr/webmail/fr_FR/read.html?IDMSG=2086&FOLDER=SF_INBOX&ORIGIN=SYSTEM_FOLDER
Cette image est appelée par les tous les lecteurs de courrier en ligne ...

Wanadoo s'amuse à utiliser nos images ?
Commentaire de Quentin de Chivré [ 16/mars/06 19:19 ]
Euh calmos... ;-)
C'est peut-etre juste une de nos newsletter tu vois...
Commentaire de Andrei Matyas [ 20/mars/06 10:59 ]
J'ai ajouté tt les images www




[EXP-2930] [INTEG FR et ES] Les deux sites d'Integ sont HS Création: 06/nov./06 10:32  Mise à jour: 25/juin/07 18:59  Résolue: 06/nov./06 17:33

Etat: Fermé
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Bloquant
Rapporteur: Younès Charrière Attribution: Younès Charrière
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Le site d'Integ Espagne me renvoie pratiquement que des pages indisponibles (pour la france c'est à peu près pareil).
Il y a des erreurs dans les logs de MIGNON :
2006-11-06 10:10:43,136 INFO [P-Processor9] 192.168.1.220 - >>> GET http://www.es.integ/navigation/default/category/dvd-zona-1
2006-11-06 10:10:43,137 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init starting
2006-11-06 10:10:43,145 ERROR [P-Processor9] 192.168.1.220 - no.fast.ds.search.SearchEngineException: Failed to connect to http://192.168.1.16:15100/cgi-bi
n/ with full url http://192.168.1.16:15100/cgi-bin/search?resultview=search&encoding=utf-8&query=and%28filter%28and%28meta.collection%3Astring%28%22ESINTEG%2
2%2C+mode%3D%22OR%22%29%2C+prdtypecode%3Astring%28%222248+2247+2243+2261+2241+2242%22%2C+mode%3D%22OR%22%29%2C+ratioprice%3Arange%28min%2C+float%280.8001%29%
2C+to%3D%22LT%22%29%2C+salescount30%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+not%28firstprdimageid%3Astring%28%220%22%2C+mode%3D%22OR%22%29%29%2C
+stockquantity%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+prdvisibilitycode%3Aint%2810%29%29%29%29&qtpipeline=priceminister&rpf_navigation:enabled=
true&hits=10&qtf_lemmatize=true&offset=0&language=es&sortby=-prdisavailable+-salescount30+default&version=v2.0.70
        at no.fast.ds.search.http.HttpSearchEngine.searchInternal(HttpSearchEngine.java:196)
        at no.fast.ds.search.http.HttpSearchEngine.search(HttpSearchEngine.java:111)
        at com.babelstore.search.FastSearch.search(FastSearch.java:123)
        at com.babelstore.search.FastSearch.search(FastSearch.java:104)
        at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:773)
        at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:822)
        at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:822)
        at com.babelstore.product.business.ProductCatalogBean.getCategoryTopMap(ProductCatalogBean.java:741)
        at com.babelstore.product.business.ProductCatalogBean.load(ProductCatalogBean.java:598)
        at sun.reflect.GeneratedMethodAccessor186.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
        at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
        at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130)
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:363)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
        at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
        at org.jboss.ejb.Container.invoke(Container.java:873)
        at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155)
        at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104)
        at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:179)
        at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:165)
        at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
        at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
        at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97)
        at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
        at $Proxy475.load(Unknown Source)
        at com.babelstore.common.business.CacheServiceBean$Cache.loadData(CacheServiceBean.java:268)
        at com.babelstore.common.business.CacheServiceBean$Cache.initData(CacheServiceBean.java:225)
        at com.babelstore.common.business.CacheServiceBean$Cache.getData(CacheServiceBean.java:187)
        at com.babelstore.common.business.CacheServiceBean$Cache.access$200(CacheServiceBean.java:151)
        at com.babelstore.common.business.CacheServiceBean.getData(CacheServiceBean.java:82)
        at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
        at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
        at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130)
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:363)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
        at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
        at org.jboss.ejb.Container.invoke(Container.java:873)
        at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155)
        at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104)
        at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:179)
        at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:165)
        at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
        at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
        at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97)
        at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
        at $Proxy445.getData(Unknown Source)
        at com.babelstore.common.business.CacheClient.getData(CacheClient.java:178)
        at com.babelstore.product.front.NavigationModel.isTopCacheInitialized(NavigationModel.java:490)
        at com.babelstore.product.front.DefaultNavigationAction.findRedirection(DefaultNavigationAction.java:102)
        at com.babelstore.product.front.DefaultNavigationAction.execute(DefaultNavigationAction.java:68)
        at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:338)
        at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:297)
        at com.babelstore.util.web.Dispatcher.innerLoad(Dispatcher.java:214)
        at com.babelstore.util.web.Dispatcher.load(Dispatcher.java:186)
        at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:152)
        at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:114)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:138)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
        at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.net.ConnectException: Connection refused
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
        at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
        at java.net.Socket.connect(Socket.java:516)
        at java.net.Socket.connect(Socket.java:466)
        at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:365)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:477)
        at sun.net.www.http.HttpClient.&lt;init&gt;(HttpClient.java:214)
        at sun.net.www.http.HttpClient.New(HttpClient.java:287)
        at sun.net.www.http.HttpClient.New(HttpClient.java:299)
        at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:796)
        at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:748)
        at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:673)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:917)
        at no.fast.ds.search.http.HttpSearchEngine.searchInternal(HttpSearchEngine.java:188)
        ... 112 more
2006-11-06 10:10:43,146 ERROR [P-Processor9] 192.168.1.220 - TransactionRolledbackException in method: public abstract java.lang.Object com.babelstore.comm
on.business.Cacheable.load(java.lang.String,java.lang.Object,java.sql.Timestamp) throws java.rmi.RemoteException, causedBy:
com.babelstore.search.SearchException: Fast Search not available.
        at com.babelstore.search.FastSearch.search(FastSearch.java:128)
        at com.babelstore.search.FastSearch.search(FastSearch.java:104)
        at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:773)
        at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:822)
        at com.babelstore.product.business.ProductCatalogBean.populateCategoryTop(ProductCatalogBean.java:822)
        at com.babelstore.product.business.ProductCatalogBean.getCategoryTopMap(ProductCatalogBean.java:741)
        at com.babelstore.product.business.ProductCatalogBean.load(ProductCatalogBean.java:598)
        at sun.reflect.GeneratedMethodAccessor186.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
        at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
        at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130)
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:363)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
        at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
        at org.jboss.ejb.Container.invoke(Container.java:873)
        at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155)
        at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104)
        at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:179)
        at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:165)
        at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
        at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
        at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97)
        at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
        at $Proxy475.load(Unknown Source)
        at com.babelstore.common.business.CacheServiceBean$Cache.loadData(CacheServiceBean.java:268)
        at com.babelstore.common.business.CacheServiceBean$Cache.initData(CacheServiceBean.java:225)
        at com.babelstore.common.business.CacheServiceBean$Cache.getData(CacheServiceBean.java:187)
        at com.babelstore.common.business.CacheServiceBean$Cache.access$200(CacheServiceBean.java:151)
        at com.babelstore.common.business.CacheServiceBean.getData(CacheServiceBean.java:82)
        at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
        at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
        at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130)
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:363)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
        at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
        at org.jboss.ejb.Container.invoke(Container.java:873)
        at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155)
        at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104)
        at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:179)
        at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:165)
        at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
        at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
        at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97)
        at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
        at $Proxy445.getData(Unknown Source)
        at com.babelstore.common.business.CacheClient.getData(CacheClient.java:178)
        at com.babelstore.product.front.NavigationModel.isTopCacheInitialized(NavigationModel.java:490)
        at com.babelstore.product.front.DefaultNavigationAction.findRedirection(DefaultNavigationAction.java:102)
        at com.babelstore.product.front.DefaultNavigationAction.execute(DefaultNavigationAction.java:68)
        at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:338)
        at com.babelstore.util.web.Dispatcher.process(Dispatcher.java:297)
        at com.babelstore.util.web.Dispatcher.innerLoad(Dispatcher.java:214)
        at com.babelstore.util.web.Dispatcher.load(Dispatcher.java:186)
        at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:152)
        at com.babelstore.util.web.Dispatcher.service(Dispatcher.java:114)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:138)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
        at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Thread.java:595)

2006-11-06 10:10:43,147 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init done in 10 ms
2006-11-06 10:10:43,149 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init starting
2006-11-06 10:10:43,156 ERROR [P-Processor9] 192.168.1.220 - no.fast.ds.search.SearchEngineException: Failed to connect to http://192.168.1.16:15100/cgi-bin/ with full url http://192.168.1.16:15100/cgi-bin/search?resultview=search&encoding=utf-8&query=and%28filter%28and%28meta.collection%3Astring%28%22ESINTEG%22%2C+mode%3D%22OR%22%29%2C+prdtypecode%3Astring%28%222248+2247+2243+2261+2241+2242%22%2C+mode%3D%22OR%22%29%2C+ratioprice%3Arange%28min%2C+float%280.8001%29%2C+to%3D%22LT%22%29%2C+salescount30%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+not%28firstprdimageid%3Astring%28%220%22%2C+mode%3D%22OR%22%29%29%2C+stockquantity%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+prdvisibilitycode%3Aint%2810%29%29%29%29&qtpipeline=priceminister&rpf_navigation:enabled=true&hits=10&qtf_lemmatize=true&offset=0&language=es&sortby=-prdisavailable+-salescount30+default&version=v2.0.70
2006-11-06 10:10:43,157 ERROR [P-Processor9] 192.168.1.220 - TransactionRolledbackException in method: public abstract java.lang.Object com.babelstore.common.business.Cacheable.load(java.lang.String,java.lang.Object,java.sql.Timestamp) throws java.rmi.RemoteException, causedBy:
2006-11-06 10:10:43,159 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init done in 10 ms
2006-11-06 10:10:43,159 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init starting
2006-11-06 10:10:43,165 ERROR [P-Processor9] 192.168.1.220 - no.fast.ds.search.SearchEngineException: Failed to connect to http://192.168.1.16:15100/cgi-bin/ with full url http://192.168.1.16:15100/cgi-bin/search?resultview=search&encoding=utf-8&query=and%28filter%28and%28meta.collection%3Astring%28%22ESINTEG%22%2C+mode%3D%22OR%22%29%2C+prdtypecode%3Astring%28%222248+2247+2243+2261+2241+2242%22%2C+mode%3D%22OR%22%29%2C+ratioprice%3Arange%28min%2C+float%280.8001%29%2C+to%3D%22LT%22%29%2C+salescount30%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+not%28firstprdimageid%3Astring%28%220%22%2C+mode%3D%22OR%22%29%29%2C+stockquantity%3Arange%28int%283%29%2C+max%2C+from%3D%22GE%22%29%2C+prdvisibilitycode%3Aint%2810%29%29%29%29&qtpipeline=priceminister&rpf_navigation:enabled=true&hits=10&qtf_lemmatize=true&offset=0&language=es&sortby=-prdisavailable+-salescount30+default&version=v2.0.70
2006-11-06 10:10:43,166 ERROR [P-Processor9] 192.168.1.220 - TransactionRolledbackException in method: public abstract java.lang.Object com.babelstore.common.business.Cacheable.load(java.lang.String,java.lang.Object,java.sql.Timestamp) throws java.rmi.RemoteException, causedBy:
2006-11-06 10:10:43,168 INFO [P-Processor9] 192.168.1.220 - Cache top_map - Init done in 9 ms
2006-11-06 10:10:43,169 ERROR [P-Processor9] 192.168.1.220 - Load error
2006-11-06 10:10:43,170 INFO [P-Processor9] 192.168.1.220 - Setting response status code to 503
2006-11-06 10:10:43,212 INFO [P-Processor9] 192.168.1.220 - <<< [75 ms] GET http://www.es.integ/navigation/default/category/dvd-zona-1


 Commentaires   
Commentaire de Antoine Koener [ 06/nov./06 16:10 ]
Ca refonctionne ?

TU peux fermer le Jira ?
Commentaire de Younès Charrière [ 06/nov./06 17:33 ]
OK parfait merci Antoine :)




[DEC-402] demande similaire à celle de Dorian pour le CD et le DVD Création: 26/juil./06 14:22  Mise à jour: 14/sept./07 14:44  Résolue: 02/nov./06 12:12

Etat: Fermé
Projet: Reporting
Composants: Trading
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Jany Marimoutou Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
J'ai besoin de rapport sur les meilleurs vendeurs de neuf d'une part, et d'occasion de l'autre :

Avec comme principales caractéristiques :
- Le nombre de vente
- Leurs stocks
- La quantités moyennes par produits
- Le prix moyen de vente
- Le CA par mois moyen

Ceci pour les catégorie suivantes :

Musique :
  - CD
  - Vinyle
  - Instruments de musique
  - Divers musique
Vidéo
  - DVD ZONE 2 (normale + à droit locatif + Précommandes)
  - DVD ZONE 1
  - VHS

En CD j'aimerai également avoir un classement par "genre musicale"

 Commentaires   
Commentaire de Agathe Remy [ 02/août/06 19:09 ]
Bonjour,

Tes rapports sur les meilleurs vendeurs ont été développés et seront mis à jour tous les lundis dans la journée.
Tu les trouveras dans l'intranet dans les répertoires à partir de lundi prochain :
http://intra.priceminister.com/stats/reports/public/Stock//Music
http://intra.priceminister.com/stats/reports/public/Stock//Video

Le prix moyen et le CA moyen par mois sont des infos trop complexes à fournir.

Quant au classement par genre musical, c'est aussi trop compliqué et gourmand en ressources.

Cordialement,
Agathe
Commentaire de Jany Marimoutou [ 31/août/06 16:11 ]
Bonjour,

Serait-il possible d'avoir en plus des éléments déjà fournis, le Chiffre d'Affaire pour chacun des vendeurs qui figure dans la liste ?

Merci
Commentaire de Agathe Remy [ 02/nov./06 12:12 ]
D'après Pascal, le reporting demandé a été mis en place via 4D en septembre.
D'autre part, afin d'éviter de faire le même travail dans 4D et BI, toutes les demandes de reporting doivent être validées au préalable par Pascal.

Merci:-)

Cordialement,
Agathe




[EXP-1631] batch holiday : il pourrait etre a l'origine de nos pb de perf. Il faudrait organiser une audit avec le dev... Création: 27/mars/06 09:38  Mise à jour: 08/août/07 19:22  Résolue: 08/août/07 19:22

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Justin Ziegler Attribution: Patrice Boulanger
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Commentaires   
Commentaire de Justin Ziegler [ 27/mars/06 09:38 ]
cf graphe / hercule (user in state transit)
j'ai l'impression que la forme est anormale
ou alors c'est peut etre des comptes avec de nombreuses annonces qui sont mis en vacances / qui reviennent ce qui demande bcp de travail au batch holidays.
 
dans tous les cas, cela pourrait etre la cause de nos pb de charge sur la base.
Commentaire de Justin Ziegler [ 27/mars/06 09:49 ]
Il pourrait etre interessant de regarder l'evenement de mise en vacances automatique afin de voir si il y a plus de mise en vacance auto qu'avant (etude a voir avec l'equipe BI).
Commentaire de Antoine Koener [ 09/août/06 10:16 ]

A correler avec les exceptions du 8 aout au soir.
Commentaire de Justin Ziegler [ 08/août/07 19:22 ]
On ferme !




[APP-10436] [Affiliation] Les stats Xiti pour l'affiliation bugent à partir de la mise en ligne du site Création: 12/juin/06 17:56  Mise à jour: 25/juin/07 18:40  Résolue: 05/juil./06 17:02

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 9.0.0.1
Version(s) corrigée(s): 9.0.1

Type: Bogue Priorité: Mineur
Rapporteur: Ghislain Gridel Attribution: Swan Desportes
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg     JPEG File screenshot-1.jpg     JPEG File screenshot-1.jpg     JPEG File screenshot-1.jpg     JPEG File screenshot-1.jpg     JPEG File XITI.jpg    

 Description   
Swan, tu remarqueras que les statistiques ne sont pas cohérentes entre la page 1 et la page 2 pour l'affiliation. L

--> problème de tag ! Il semble ne plus être pris en compte à partir du 6 juin.

cf copies-écran

Merci


 Commentaires   
Commentaire de Swan Desportes [ 14/juin/06 09:57 ]
Il y avait un problème de syntaxe sur l'EntryEventBlock suite à l'ajout d'un alt="" pour la conformité XHTML : corrigé.
D'autres problèmes possibles : l'utilisation d'un &amp; au lieu d'un & dans les URL. Il est possible que cela soit mal interprété par certains navigateurs : retour à la précédente syntaxe.
On espère un retour à l'ordre suite à la mise en prod de la nuit prochaine --> les stats de Jeudi (visible Vendredi) devraient être bonnes.
Commentaire de Christophe Garcia [ 15/juin/06 17:32 ]
A vérifier en live sur la PROD demain
Commentaire de Ghislain Gridel [ 19/juin/06 10:29 ]
Bonjour Swan,

après vérification les stats bugent toujours. cf copie écran.
Commentaire de Swan Desportes [ 19/juin/06 12:50 ]
Effectivement, un second bug trainait :
<script type="text/javadscript"> au lien de <script type="text/javascript">
Cette faute faisait que le tag Entrée n'était pas interprêté...
Commentaire de Ghislain Gridel [ 05/juil./06 11:10 ]
Au 05/07/06, les résultats du tracking Xiti semblent toujours très faible. Jen conclue que le bug n'est pas réparé.

Pouvez-vous revenir vers moi avec un diagnostic ?

Merci !

Ghislain
Commentaire de Swan Desportes [ 05/juil./06 11:26 ]
En regardant XITI Tracking, tout semble etre en ordre sur le tag Entrée. Les stats "Entrée" sont de nouveau volumineuses.
Commentaire de Swan Desportes [ 05/juil./06 11:32 ]
Cette baisse de volume est un problème d'un autre ordre. Est on en contradiction avec Effiliation ?
Que donnent les rapport BI sur le tracking Effiliation ?
Commentaire de Swan Desportes [ 05/juil./06 17:02 ]
vu avec Ghislain, c'est ok
Commentaire de Lydia Dali [ 05/juil./06 18:01 ]
http://v50.xiti.com/stats/frequentation/vvp_courbe.asp?d=05/06/2006&f=04/07/2006&ng=0-0&q2=7912&q8=1

ok




[CAT-328] Rédaction d'une document de spécification - Chiffrage sur les BBD Produits Création: 22/sept./06 14:22  Mise à jour: 03/juil./08 16:19  Résolue: 03/juil./08 16:18

Etat: Résolu
Projet: Paramétrage - Non Import
Composants: Référentiel
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Marion Anfreville Attribution: Marion Anfreville
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: 15 minutes
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word Alerte_livraison_SPEC.doc     Text File requete_rapport_erreurs_hebdo.txt     Microsoft Word SPEC_BDD_Controle_Qualite.doc    
Pays:
FRA - France

 Description   
Rédiger un document de spécifications sur la mise en place de rapports sur les données présentes dans nos bases.

 Commentaires   
Commentaire de Marion Anfreville [ 21/mai/07 16:41 ]
Actuellement, la spécification contient les grandes lignes pour la mise en place d'alertes et rapports pour un meilleur suivi des BDD produits.

La spécification ne pourra être finalisée sans avoir tous les éléments techniques de réalisation.

Pour le moment, le côté rapports est en suspend à cause du chantier sbp. Le rapport pourrait être fourni par l'équipe BI mais ils attendent ce chantier pour intégrer les attributs à business object.
Commentaire de Marion Anfreville [ 25/mai/07 17:39 ]
en pj, le document de spécification des besoins alertes => Alerte_livraison_SPEC.doc
Commentaire de Marion Anfreville [ 03/juil./08 16:19 ]
V1 des alertes mis en place. A étoffer par la suite.




[BIN-155] [Affiliation] : rapport affiliation acheteurs Création: 19/sept./06 13:23  Mise à jour: 14/sept./07 17:20  Résolue: 05/mars/07 17:18

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Ghislain Gridel Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Dépendance
bloque BIN-285 [Affiliation] : mise en place du rapp... Fermé
Pays:
FRA - France

 Description   
Agathe,

Cela fait plusieurs mois que nous parlons du rapport de validation des ventes pour l'affiliation. La demande avait été faite par François-Marie à l'époque.

Quand ce rapport pourra-t-il être réalisé ?

Ghislain

 Commentaires   
Commentaire de Agathe Remy [ 19/sept./06 14:01 ]
Ghislain,

Nous pourrons traiter cette demande en même temps que le rapport d'affiliation.
J'ai plannifier ce projet d'ici fin 2006, après les projets 1000Mercis et BI Espagne, à savoir en décembre.

Cordialement,
Agathe
Commentaire de Agathe Remy [ 09/oct./06 12:46 ]
Vu avec OSA : ce rapport passe en P2.

Agathe
Commentaire de Romain Czornomaz [ 21/févr./07 17:59 ]
Les modifications du rapport sont OK. Tu peux le valider sur le dev.

Merci,

Romain




Affiliation Programme Vendeur :: Metatache (APP-15282)

[APP-15295] Création du rapport des ventes Création: 23/févr./07 16:23  Mise à jour: 25/oct./07 14:33  Résolue: 27/juil./07 15:58

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation
Affecte la/les version(s): ToDo
Version(s) corrigée(s): 17.0.0

Type: Sous-tâche Priorité: Mineur
Rapporteur: Ghislain Gridel Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Projets PM: *** RESERVE ***
Projets PM archivés: Affiliation vendeur

 Commentaires   
Commentaire de Ghislain Gridel [ 23/févr./07 16:25 ]
Romain,

il s'agit de créer un rapport pour pouvoir valider les ventes (on parlera désormais de validation des achats pourle programme achat).

Voilà les éléments dont nous aurions besoin :

GROUPE DE TRACKING
TRACKING
LOGIN
EMAIL
DATE ET HEURE DE MISE EN VENTE
N° ANNONCE
PREMIERE MISE EN VENTE OU NON
ANNONCE VENDUE OU NON

A ta dispo pour toute question

Ghislain
Commentaire de Romain Czornomaz [ 27/juil./07 15:58 ]
Ghislain,

Les rapport BI pour suivre l'affiliation vendeur sont déployés.

Bonne journée,

Romain




[DEC-459] Ecart Tableau de bord / articles Création: 28/sept./06 16:26  Mise à jour: 14/sept./07 15:19  Résolue: 19/janv./07 18:08

Etat: Fermé
Projet: Reporting
Composants: Trading
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Benjamin Guerville Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,
je remarque des écart de chiffres entre le tableau de bord et l'item history.

Exemple : ventes de mobiles le 01/09/2006

Tabeau de bord : 17 336
Somme items (sauf supprimés) : 16 797,63
Somme items + port (sauf supprimés) : 18053,80
Somme items (avec supprimés) : 21 523,04
Somme items + port (avec supprimés) : 23 116,84

A quoi correspond exactement la somme indiquée dans le tableau de bord.

Merci


 Commentaires   
Commentaire de Agathe Remy [ 19/janv./07 18:08 ]
Les données du tableau de bord BackOffice ne sont pas produites par le pôle BI et ne sont pas maintenues par les pôle Développement. Elles ne sont donc pas fiables.

Cordialement,
Agathe




[BIN-160] NpF - nb de produits par famille Création: 29/sept./06 16:15  Mise à jour: 14/sept./07 17:20  Résolue: 25/oct./06 18:48

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Bloquant
Rapporteur: Estelle Coulon Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 1 jour
Temps consacré: Non spécifié
Estimation originale: 1 jour

Pièces jointes: Microsoft Excel Nombres de produits par type.xls    
Pays:
FRA - France

 Description   
Agathe,

Comme évoqué hier je souhaiterai obtenir les données suivantes par famille:

Nb de produits avec annonces
Nb de produits sans annonces
Nb de FP active
Nb de FP non active

En fait les données d'Emmanuel ne sont pas bonnes car je pense que ces requetes sous Business Objects sont ko.
Merci de voir quand tu peux faire ca, idealement rapidement.
Estelle

 Commentaires   
Commentaire de Agathe Remy [ 29/sept./06 16:58 ]
Ta demande sera priorisée en P1/P2 BI vendredi prochain.

Merci:-)

Agathe
Commentaire de Estelle Coulon [ 24/oct./06 14:51 ]
Quel est le resultat de la priorisation?
Je suis tjs preneuse de cette info.
merci
Estelle
Commentaire de Agathe Remy [ 25/oct./06 18:48 ]
Tu trouveras ci-joint les données demandées.
J'espère qu'elles te conviendront.
N'hésite pas à venir me voir si tu as des questions:-)

Agathe




[I18N] Refonte Country (APP-11799)

[APP-13152] Changement de schéma pour les tables CURRENCY, STATE, EXCHANGE_RATE Création: 16/oct./06 14:22  Mise à jour: 25/juin/07 18:45  Résolue: 15/mars/07 14:18

Etat: Fermé
Projet: Application PriceMinister
Composants: Base de données
Affecte la/les version(s): 9.0.3.1.c
Version(s) corrigée(s): 14.0.0

Type: Sub-bug Priorité: Mineur
Rapporteur: Renaud Dierickx Attribution: Edouard Gomez-Vaez
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Liens des demandes:
Dépendance
bloque APP-13424 [UK beta] Adaptation fonctionnelle : ... Fermé
Pays:
ALL - Tous
Classif1: I18N
Classif2: I18N - finition currency
Projets PM archivés: Maintenance 11.0.0

 Description   
Salut Patrick,
Peux-tu déplacer dans admin_1 les tables CURRENCY et STATE ?
Il semblerait qu'EXCHANGE_RATE ne soit plus utilisé (elle est vide dans purchase) si c'est le cas, peux-tu la supprimée ?
Merci d'avance.

 Commentaires   
Commentaire de Renaud Dierickx [ 02/nov./06 17:49 ]
J'ai supprimé la table 'exchange_rate' car elle n'était jamais utilisée... Il faudra voir si on souhaite la recréer pour la refonte currency (voir screenshot-1)
Commentaire de Renaud Dierickx [ 02/nov./06 18:35 ]
Les scripts sont écris... On les passe pour quelle version ??? La V1000 ou celle d'après ???
Si on les passe, il faut que Patrick P pense à y ajouter un synonyme pour le BI dans le script 3. C'est critique !!!
Commentaire de Arnaud Forgues [ 03/nov./06 11:30 ]
on va plutot attendre après la V10.

Par contre il reste à faire les scripts pour la table STATE
Commentaire de Renaud Dierickx [ 03/nov./06 12:44 ]
C'est fait... J'ai mis mes scripts dans le répertoire waiting et j'attends de voir comment on va procéder pour la prochaine version...
Commentaire de Edouard Gomez-Vaez [ 02/mars/07 16:30 ]
test jira
Commentaire de Edouard Gomez-Vaez [ 02/mars/07 18:50 ]
test JIRA
Commentaire de Renaud Dierickx [ 15/mars/07 12:23 ]
Tu en es où dans ton test ??? Je te réassigne le jira.
Commentaire de Edouard Gomez-Vaez [ 15/mars/07 14:18 ]
Désolé, je la ferme !




[EXP-2858] archivage des data OLTP : prévoir un axe d'archivage pour usr_event Création: 18/oct./06 14:55  Mise à jour: 15/sept./08 10:55  Résolue: 15/sept./08 10:55

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Justin Ziegler Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Commentaires   
Commentaire de Patrick Pereira [ 14/avr./08 18:00 ]
Bloqué en attente du développement par l'équipe BI d'un client permettant de consulter les usr_event sur la base d'archive.
Commentaire de Ayoub Benseghir [ 14/août/08 11:23 ]
L'archivage et l'épuration de USR_EVENT sont en place, on a libéré la prod de 200M de lignes (+- 12Go de données).




[EXP-3199] mise à jour plages de ecb Création: 29/janv./07 14:01  Mise à jour: 08/janv./10 15:07

Etat: Ré-ouvert
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Steven Harel Attribution: Arnaud Forgues
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à APP-15131 [CoSAV] Conservation des 6 premiers c... Fermé
Pays:
ALL - Tous

 Description   
on a un gros souci avec les ecartes depuis pas-mal de temps
y'a plein de coupons utilisés frauduleusement :
une partie du budget marketing/coupon part chez les fraudeurs
(et pas pour le recrutement des nouveaux acheteurs)
qui créent autant de compte et font autant d'achat qu'ils ont de ecartes

au bo, on passe notre temps à essayer de les chopper et on n'y arrive pas souvent
le dernier qu'on a attrapé nous devait 15.000 euros !!

pourquoi ?
parce que la base des ecartes intégrée dans le système n'est pas à jour
c'est ce qui nous permet d'identifier et de refuser les commandes ecarte/coupon

benoit a réussi à avoir les plages mises à jour
est-ce que tu penses qu'on peut facilement/rapidement ajouter
les nouvelles plages à celles que l'on a déjà paramétrées ?



 Commentaires   
Commentaire de Patrice Boulanger [ 29/janv./07 18:45 ]
Steven,

Peux-tu nous mettre le contenu de la base dans ce jira? Ensuite, on pourra le passer sur les serveurs applicatifs.

Il faut préciser si c'est une base complète ou une mise à jour.

Merci.
Patrice.
Commentaire de Steven Harel [ 30/janv./07 10:05 ]
c'est a priori une mise à jour, il y aurait des plages supplémentaires, d'autres auraient été modifiées. il faut intégrer les 6 premiers chiffres des numéros de cb suivants

la ecb est une grosse faille dans notre système si les infos ne sont pas correctement paramétrées. on a vu que certains utilisateurs nous faisaient perdre des dizaines de milliers d'euros. il est vraiment indispensable que tu t'assures que ces pages sont paramétrées parfaitement vu qu'il n'est pas vraiment possible de faire des tests derrière.

société générale :
415056

caisse d'épargne
420110
420111
420112
420113
420114
420115
420116

lcl :
415055

banque postale (visa) :
415059

banque postale (ecmc) :
513001

banque pop :
415058

415060
415061
415062
415063
415064
415065
415066
415067
415068
415069
415070
415071
415072
415073
415074

405935
405936
405937
405938
405939
405940
405941
405942
405943
405944


Commentaire de Steven Harel [ 15/févr./07 14:29 ]
peux-tu me donner le détail des différences entre la base actuelle et la nouvelle ?

merci
Commentaire de Patrice Boulanger [ 15/févr./07 15:38 ]
Je retrouve tous les numéros ci-dessus dans la base actuellement en prod.
Commentaire de Patrice Boulanger [ 15/févr./07 15:40 ]
Plus précisément, il y a aussi les numéros suivants en prod:

41506
415935
415936
415937
415938
415939
415940
415941
415942
415943
415944
496612
497612
497784
513220
513226
513284
513612
529477
 


Commentaire de Steven Harel [ 28/févr./07 13:49 ]
nous allons créer nos propres plages de ecb.
notamment en identifiant les fraudes ecb/coupon et en demandant systématiquement les 5ème et 6ème chiffre de la ecb

nous aurons de nouvelles infos régulièrement
peut-on laisser ce jira ouvert et communiquer les nouveaux chiffres par ce biais ?

la première plage qui pose de gros problèmes est :
5132 68

peux-tu l'intégrer dans le système le plus rapidement possible ?
merci
Commentaire de Patrice Boulanger [ 09/mars/07 12:28 ]
Jérémie,

Merci d'ajouter le numéro ci-dessous dans la propriété

priceminister.purchase.ecartebleue

sur tous les JBOSS.

On garde donc le JIRA ouvert pour suivre les mises à jour.
Commentaire de Jérémie Bennejean [ 09/mars/07 12:55 ]
La maj est faite sur tous les jboss.
Je baisse la priorité et je laisse le jira ouvert pour de nouveaux ajouts si besoin est.
Commentaire de Eve Pioche [ 29/juil./09 15:47 ]
MAJ

4 nouvelles plages e-CB détectées à ajouter en prod :

Caisse d'épargne :
- 420117
- 420118

Crédit Mutuel :
- 497768

Banque non indentifiée (Portugal ?)
- 465963

Merci
Commentaire de Eve Pioche [ 29/juil./09 15:53 ]
Une autre plage qui n'est semble t-il pas encore en prod non plus :

- 513201
Commentaire de Jérémie Bennejean [ 07/janv./10 17:46 ]
Nicolas,
Je te transfère ce jira car la property se trouve dans le priceminister.properties.
Je ne préfère pas l'overloader, sinon ca va devenir ingérable.
Commentaire de Nicolas Chauveau [ 07/janv./10 18:00 ]
A passer en TX-L
Commentaire de Arnaud Forgues [ 08/janv./10 15:07 ]
Donc la propriété à mettre à jour est bien la suivante ?
priceminister.purchase.ecartebleue =

Jérémie, quelle(s) est(sont) la(les) bonne(s) valeur(s) à mettre par rapport à la PROD (FR / ES / UK) ?

D'autre part, je ne vois pas d'inconvénient à mettre à jour les dernières valeurs de cette propriété directement dans le priceminister.properties, mais, à mon avis, il s'agit d'un cas de propriété qui correspond bien à l'utilisation de l'overload : cela est indépendant de l'application / dev et évolue donc en permanence ...




Installation de la solution de sauvegarde (EXP-2751)

[EXP-2755] Définition de la stratégie de sauvegarde Création: 29/sept./06 11:18  Mise à jour: 17/sept./08 09:31  Résolue: 17/sept./08 09:31

Etat: Résolu
Projet: Exploitation
Composants: Installation
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Mineur
Rapporteur: Patrice Boulanger Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Commentaires   
Commentaire de Patrice Boulanger [ 29/sept./06 11:19 ]
Ce jira rassemble les éléments nécessaire pour la mise en place de la stratégie de sauvegarde (qu'est-ce-qu'on backup ? quand ?)
Commentaire de Patrice Boulanger [ 29/sept./06 11:21 ]
Comptabilité:

backup les données CEGID.

Quand? tous les jours ouvrés (lundi-vendredi) à 21h
Quoi? le dump de la base MSSQL qui est effectuée automatiquement à 20h
Retention: à définir avec Philippe Favrot
Commentaire de Patrice Boulanger [ 29/sept./06 11:22 ]
BI:

Agathe m'a parlé d'un JIRA qui a été fait avec Jérémie il y a deux mois... Jérémie peux-tu retrouver ces infos?
Commentaire de Patrice Boulanger [ 29/sept./06 11:23 ]
Données utilisateurs:

Quand? tous les jours durant la nuit (minuit?)
Quoi? le contenu de tous les répertoires utilisateurs
Retention: à définir

 
Commentaire de Patrice Boulanger [ 29/sept./06 11:24 ]
Base de données:

backuper les bases de données des outils: JIRA, Sysaid, ...

Quand? Tous les jours durant la nuit (minuit?)
Quoi? à voir avec Patrick? stopper la base la nuit et backuper les fichiers?
Retention: à définir
Commentaire de Patrice Boulanger [ 29/sept./06 11:26 ]
Réaliser un document (sur le wiki exploit) pour expliquer la stratégie de sauvegarde.
Ce document sera publié pour information aux utilisateurs après la mise en place définitive de la politique de sauvegarde.
Commentaire de Patrice Boulanger [ 29/sept./06 11:27 ]
Arnaud,

Peux-tu voir avec Philippe pour la rétention nécessaire des données?

Si ce délai est très long, il faudra prévoir de réserver des tapes spécifiques pour ce contenu. A voir avec le consultant qui installera la solution de sauvegarde.
Commentaire de Patrice Boulanger [ 29/sept./06 12:23 ]
Voir aussi avec Philippe s'il y a d'autres données financières/RH à sauvegarder. Peut-être lui créer un lecteur réseau spécifique qui sera aussi sauvegarder sur la tape spécifique à la compta.

Merci.
Commentaire de ZZ_Arnaud Baali [ 29/sept./06 17:14 ]
J'ai vu avec philippe pour la rétention d'informations: il n'y a aucune limite de conservation dans le temps. Il faudra donc disposer de cassettes à remplir indéfiniement pour les données de comptas d'une année sur l'autre
Commentaire de Patrice Boulanger [ 29/sept./06 17:38 ]
En même temps, il faudra décrire ce cas à l'intégrateur pour en discuter avec lui. Il y a peut être une meilleure solution. Si on laisse ce genre d'info sur une seule bande et qu'elle est défectueuse, volée, perdue, brûlée, ... on perd tout !!!
Commentaire de Patrice Boulanger [ 27/oct./06 15:51 ]
Arnaud,

Afin de commencer cette tâche, pourrais-tu commencer par faire une estimation de la volumétrie totale des différents serveurs de la plateforme interne?

Merci.

Commentaire de Quentin de Chivré [ 06/juil./07 16:01 ]
Arnaud Baali -> Patrice
Commentaire de Patrice Boulanger [ 20/août/07 14:08 ]
Jérôme,

Merci de nous mettre ici la liste des serveurs backupés avec une estimation de la volumétrie (ça sera à reprendre dans le rapport service desk). On pourra ensuite clore cette sous tâche.

Merci.
Commentaire de Ange Ferrari [ 16/sept./08 17:48 ]
Je sais pas si c'est toujours d'actualité mais comme tu es le roi de la sauvegarde Stéphane :)
Commentaire de Stéphane Eccli [ 17/sept./08 09:31 ]
ok




[EXP-3135] Réalisation d'un Export pour Mixad. Création: 03/janv./07 15:30  Mise à jour: 25/juin/07 19:00  Résolue: 21/févr./07 14:57

Etat: Résolu
Projet: Exploitation
Composants: Flux
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Benoît Bourdon Attribution: Edouard Laurent
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel PM - Mixad-retour yves 2006-02-07.xls    
Liens des demandes:
Duplicate
a pour doublon APP-14470 Envoi de flux auto vers Mixad Fermé
Pays:
FRA - France

 Description   

Les champs sont décrit dans le fichier excel joint.

Dans un premier temps on génère un export pour aujourd'hui pour qu'ils testent.
On attend les commentaire de MIXAD lundi, puis on génèrera des exports quotidiens.

Cet Export concerne l'export des annonces Auto uniquement pour les PRO

Les champs attendus sont en pièces jointes dans le fichier Excel.
Je peux passer te voir pour le completer ( pour : nom du champ et de la table concernée en base)











 Commentaires   
Commentaire de Benoît Bourdon [ 08/janv./07 16:50 ]
Voici les retouches suite aux retours du client :

- Retirer les photos génériques (quand il n'y a pas de photo pour le produit complement)
- Quand il y a une photo, selectionner la grande version ( "_L" à la place de "_S " à la fin du nom de la photo)
- Supprimer les champs suivants :
       o Nombre de chevaux fiscaux
       o Cylindrée
       o Nombre de vitesse
       o Couleur intérieure

Cet export devait être bi-hebdo. si ce n'est pas possible - quotidien semble plus simple - autant le faire quotidien.

Le fichier généré est à déposer sur le FTP suivant :
ftp.mixad.com
login : priceminister
password : pm#;1428
(on peut ré-écraser tous les jours le fichier de la veille, pas de soucis)

Idéalement pour eux il faudrait envoyer un fichier non compressé.

Merci Edouard.

Tu pourra m'envoyer la requete que je l'ajoute dans la doc que j'ai fait pour cet export.

Commentaire de Edouard Laurent [ 09/janv./07 11:37 ]
C'est en place, le flux est envoyer quotidiennement sur leur ftp
Commentaire de Benoît Bourdon [ 26/janv./07 14:35 ]
Flux mis en oeuvre :
liste des évolutions possible (mais non souhaités pour l'instant)

Ø Envoyer plusieurs photos lorsqu'il y en a.
Ø Augmenter le nombre d'attributs que nous envoyons (il faut avant mesurer l'impact sur référencement par rapport au gain ?)
Ø Format « TOP vendeur » (mais il faut que le concessionnaire et ses coordonnées complètes soir dans la base des concessionnaires Mixad + il faut envoyer plusieurs photos + une description plus complète) -> Idem point ci-dessus : à voir si impact réferencement / gain
Ø Ajouter l'attribut « segment » dans le flux (l'intérêt se situe pour les voitures type cabriolet / coupé / sport que nous réunissons en une seule catégorie et que Mixad « dispatch » en plusieurs - ça suppose que ce champ soit aussi renseigné par les PROs pour les imports)
Ø Eviter le doublonnage d'annonces issues de notre base (dû, chez nous entre autre, à des véhicules appartenant à plusieurs catégories).

 
(avant mise en oeuvre - il faudra mesurer le risque que cela génère au referencement - duplicate content - par rapport au gains génèrés par le flux ...)
Commentaire de Benoît Bourdon [ 20/févr./07 10:34 ]
Comme vu par mail :
Il faut quue nous limitions le nombre d'annonces sur :
La date de modification de l'advert en prennant les annonces de moins de 30 jours.
Merci !
Commentaire de Edouard Laurent [ 21/févr./07 14:57 ]
Voila c'est en place : modification en prod a partir de demain soit 22 fev 2007




[APP-13675] Valeurs NULL dans champs ALLOW_PICKUP et ALLOW SHIPPING Création: 08/nov./06 17:09  Mise à jour: 20/nov./07 16:52  Résolue: 05/oct./07 12:08

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 18.0.0

Type: Bogue Priorité: Cosmétique
Rapporteur: François Le Lay Attribution: Mostafa Diane
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***
Classif1: DB

 Description   
Nous avons remarqué que les champs ADVERT.ALLOW_PICKUP et ADVERT.ALLOW_SHIPPING ont des valeurs NULL, 0 et 1.
Il s'agit d'annonces voitures essentiellement, créées entre Juin 2005 et Mars 2006. A priori suite à la mise place de cette fonctionnalité les anciennes annonces voitures n'ont pas eu ces champs updatés. A noter que certains autres types de produits sont concernés mais sur des cardinalités moindres.

SELECT TRUNC(CREATION_DATE,'MM'),
        PRD_TYPE_CODE.LABEL,
        ADV_STATUS_CODE.LABEL,
        COUNT(*)
FROM ADVERT, PRD_TYPE_CODE, ADV_STATUS_CODE
WHERE ALLOW_PICKUP IS NULL
AND ADVERT.PRD_TYPE_CODE = PRD_TYPE_CODE.PRD_TYPE_CODE
AND ADVERT.ADV_STATUS_CODE = ADV_STATUS_CODE.ADV_STATUS_CODE
GROUP BY TRUNC(CREATION_DATE,'MM'), PRD_TYPE_CODE.LABEL, ADV_STATUS_CODE.LABEL
;

01/06/2005 Voitures Active 1496
01/06/2005 Voitures Fermée 2955
01/07/2005 Voitures Active 1366
01/07/2005 Voitures Fermée 3057
01/08/2005 Voitures Active 1831
01/08/2005 Voitures Fermée 2658
01/09/2005 Voitures Active 1955
01/09/2005 Voitures Fermée 4564
01/10/2005 Voitures Active 1178
01/10/2005 Voitures Fermée 5778
01/10/2005 Voitures Brouillon 97
01/10/2005 Voitures En attente de publication 151
01/10/2005 Voitures_c Fermée 6
01/11/2005 Voitures Active 440
01/11/2005 Voitures Fermée 3217
01/11/2005 Voitures Brouillon 305
01/11/2005 Voitures En attente de publication 277
01/12/2005 Voitures Active 267
01/12/2005 Voitures Fermée 1908
01/12/2005 Voitures Brouillon 205
01/12/2005 Voitures En attente de publication 171
01/12/2005 Voitures_c Fermée 1
01/01/2006 Voitures Active 490
01/01/2006 Voitures Fermée 2581
01/01/2006 Voitures Brouillon 352
01/01/2006 Voitures En attente de publication 177
01/02/2006 Voitures Active 347
01/02/2006 Voitures Fermée 1190
01/02/2006 Voitures Brouillon 232
01/02/2006 Voitures En attente de publication 91
01/02/2006 Livres anciens Fermée 1
01/03/2006 Vêtements Active 5
01/03/2006 Vêtements Fermée 1
01/03/2006 Décoration Active 3
01/03/2006 Livres anciens Fermée 14
01/03/2006 Abonnements Presse Active 8
01/03/2006 Emetteur-récepteur Fermée 1
01/03/2006 Livres en pré-commande Fermée 3
01/03/2006 FB Equipements scolaires Fermée 1


 Commentaires   
Commentaire de Mostafa Diane [ 05/oct./07 12:08 ]
Effectivement les champs ALLOW_PICKUP et ALLOW SHIPPING peuvent être null. Ca vient de la non mise à jour de la table advert. (a noter que il y'a plusieurs champs sur advert qui sont null).

J'ai vu avec Samir et il m'a confirmé que les deux champs sont nullable sur la base de BI, je peux confirmer que au niveau applicatif ca nous ne gène pas d'avoir ces champs nulls. je crois, sans être pourtant sur a 100 %, que on n'a pas jugé necessaire d'initialiser les champs car l'initialisation est trop couteuse.

Si jamais vous avez une raison pour que les deux champs soint NOT NULL, ouvre moi au autre jira.
Commentaire de Nicolas Chauveau [ 12/oct./07 08:51 ]
Tag oublié [CAJ200710]
Commentaire de Agathe Remy [ 12/oct./07 13:33 ]
Bonjour,

Le JIRA avait été ouvert à la demande de l'équipe dév afin qu'un jour soi traitée l'initialisation.
En effet, il n'y a pas de blocage applicatif parce que sinon le JIRA aurait eu une priorité plus haute:-)

C'est juste une histoire de cohérence des données (tous les autres flags du même type sont initialisés) afin de pouvoir les exploiter.

Merci:-)
Agathe




[EXP-2957] Mise à jour perignon en Red Hat AS4 Création: 08/nov./06 12:59  Mise à jour: 25/juin/07 18:59  Résolue: 08/mars/07 16:03

Etat: Fermé
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: François Le Lay Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Dépendance
bloque BIN-221 Migration Business Objects XI Release 2 Fermé
Pays:
FRA - France

 Description   
Dans le cadre du projet de migration Business Objects XI vers XI Release 2 j'ai besoin que perignon soit upgradée en AS4 (Actuellement en AS3 Update 6).
Désolé ;)



 Commentaires   
Commentaire de Jérémie Bennejean [ 09/nov./06 15:12 ]
La nouvelle version de RH as4 est en cours de telechargement.
Attention une fois la maj faite on ne peut plus faire machine arriere...
Commentaire de François Le Lay [ 10/nov./06 11:21 ]
OK pour le passage en AS4. J'ai backupé le nécessaire.
Commentaire de François Le Lay [ 10/nov./06 11:36 ]
En fait il serait bien de procéder au backup de /home/bo sur disque dur sur une autrre machine.
Commentaire de Jérémie Bennejean [ 10/nov./06 11:40 ]
Très bien, je vias mettre les données sur henriot.
Je vais backuper /data1/home/bo
Par contre je pense qu'il faut mieux stopper Bo durant le backup ?
Quand puis-je faire cela ?
Commentaire de François Le Lay [ 10/nov./06 12:58 ]
Le tar.gz a fini a 12h15
Commentaire de Jérémie Bennejean [ 10/nov./06 15:19 ]
J'ai déplacé les données
Commentaire de Jérémie Bennejean [ 10/nov./06 16:18 ]
Les cd sont finis ont finis d'être telechargés
Commentaire de Jérémie Bennejean [ 10/nov./06 16:18 ]
Et en cours de gravure
Commentaire de Patrice Boulanger [ 15/nov./06 14:53 ]
Suite à la discussion avec Agathe, nous allons procéder ainsi:

1. l'exploit crée un compte "bo" sur le serveur Giraud (192.168.1.4)
1bis. l'exploit install l'arborescence /appli et /data + JDK sur Giraud
2. le B.I. installe la nouvelle version de BO sur Giraud et importe les données depuis Pérignon
3. dès que l'install est validé, l'exploit met à jour Pérignon en RH AS 4 Update 4
4. le B.I. ré-importe les données depuis Giraud.

NB: Pérignon est une architecture 32 bits, Giraud est une architecture 64 bits. Ca ne devrait pas être gênant.
Commentaire de François Le Lay [ 15/nov./06 17:13 ]
Je viens de vérifier la doc BO:
(1) Linux support is limited strictly to the 32-bit versions of Linux operating on either 32 or 64-bit (x86) AMD/Intel chipsets. BusinessObjects Enterprise software for Linux is not warranted or supported for use on other chipsets.

Donc étant donné que giraud est monté avec un noyau 64 bits, il faut passer sur une autre machine, toujours en AS4 mais avec une configuration proc 64+noyau 32 bits ou proc 32/noyau 32.
Commentaire de François Le Lay [ 15/nov./06 17:18 ]
Il faut également installer le package compat-libstdc++-33-3.2.3-47.3.i386.rpm
Commentaire de Jérémie Bennejean [ 15/nov./06 17:45 ]
Comme vu avec Patrice, on passe sur Salon
Commentaire de Jérémie Bennejean [ 15/nov./06 17:51 ]
Le user bo est créé à l'identique
le group dba aussi
Le home est en cours de copie
Commentaire de Jérémie Bennejean [ 16/nov./06 11:30 ]
compat-libstdc++-33-3.2.3-47.3.i386.rpm installé
Commentaire de François Le Lay [ 16/nov./06 11:56 ]
Par ailleurs, un home oracle est nécessaire sur salon.
Copie de lelay@ruinart:~/oracle.tar.gz dans salon:/home et mise en place des librairies client oracle, tnsnames et .bashrc
Commentaire de François Le Lay [ 16/nov./06 11:57 ]
le user bo a le groupe 520 dans /etc/passwd
lui affecter le groupe dba:501 serait plus adéquat?
et par ailleurs passer un chgrp récursif sur le home bo.
Commentaire de Jérémie Bennejean [ 16/nov./06 12:06 ]
Rajout du group oinstall avec le gid 520 su salon
Commentaire de Agathe Remy [ 22/nov./06 14:37 ]
Jérémie,

Nous avons terminé la migration sur salon : perignon t'appartient.

Sachant que nous ne pouvons plus faire de mise en production tant que perignon sera en cours de migration, ce serait bien que la migration RedHat soit faite d'ici lundi 27 novembre.

Merci:-)

Agathe
Commentaire de Jérémie Bennejean [ 23/nov./06 17:12 ]
Vu avec Agathe et Patrice, Perignon reste en AS3 et actif ainsi que salon.
Commentaire de Jérémie Bennejean [ 08/mars/07 16:03 ]
abandonné.
C'est brice qui va remplacer perignon




[BIN-214] [Finance] : Ecart sur claims du mois d'octobre 06 Création: 08/nov./06 09:11  Mise à jour: 04/sept./08 18:43  Résolue: 04/sept./08 18:43

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Philippe Favrot Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Synthèse claims.xls    
Pays:
FRA - France

 Description   
Agathe,
écart dans les données Titan et les données BO au niveau des claims pour l emois d'octovre ; par exemple :
                                                        Titan Bo
ZVRA :
nbre 7 159 5 062
comm item annulées 30,7 k¿ 20,9 k¿
comm shipping annulées 7,7 k¿ 5,3 k¿
PVRA :
nbre 1 669 1 185
buyer bonus 23,1 k¿ 16,1 k¿
PVZA :
nbre 646 541
Merci
Philippr

 Commentaires   
Commentaire de Philippe Favrot [ 22/nov./06 19:34 ]
je complète ce Jira suite à notre réunion de ce soir.

Par ailleurs, des écarts existent sur les données historiques (période 2001 / 30 juin 2006) au niveau des ZVRA et des PVRA.
Voir le fichier joint ; 2 onglets "synthèse ZVRA" et "synthèse PVRA". Les écarts sont surlignés en orange.

Philippe
Commentaire de Agathe Remy [ 05/déc./06 16:17 ]
Les écarts étaient dus à 2 problèmes :
- problème de mise à jour des items entre le 10/10/2006 et le 10/11/2006 : les données ont été mises à jour.
- problème dans la condition sur la période de fermeture de la réclamation : nous devons attendre la fin de la migration BO pour corriger ce problème, à savoir fin de cette semaine.

Cordialement,
Agathe
Commentaire de Agathe Remy [ 12/déc./06 17:32 ]
Les mises en production BI refonctionnent depuis ce matin (après deux semaines de panne):-)

La condition sur la période de fermeture de la réclamation a donc été corrigée.

Cordialement,
Agathe
Commentaire de Philippe Favrot [ 21/déc./06 15:53 ]
voir écart sur le passé
Commentaire de Philippe Favrot [ 26/déc./06 08:33 ]
Agathe,
merci de laisser une priorité critique à ce Jira.
En effet tant que les écarts sur le passé n'ont pas été expliqués, je ne peux pas utiliser ce rapport pour enregistrer les claims dans les comptes ; je continue donc à utiliser Titan, ce qui n'est pas satisfaisant car on a vu que Titan ne reprenait pas l'intégralité des éléments constuituant les claims.
Merci
Philippe
Commentaire de Agathe Remy [ 25/juil./08 20:41 ]
Philippe,

Qu'en est-il de ce JIRA?

Agathe
Commentaire de Agathe Remy [ 04/sept./08 15:05 ]
Bonjour Philippe,

Dernière relance avant fermeture:-)

Peux-tu me confirmer la clôture de ce JIRA?

Merci.

Agathe
Commentaire de Philippe Favrot [ 04/sept./08 18:39 ]
Hello,
à clôturer bien évidemment.
Merci
Philippe




[APP-13926] Mail Abandonniste :: Enquête en ligne Création: 29/nov./06 14:47  Mise à jour: 25/juin/07 18:47  Résolue: 12/déc./06 09:33

Etat: Fermé
Projet: Application PriceMinister
Composants: Mails, News Letters
Affecte la/les version(s): 11.0.0 (Merge et Maintenance)
Version(s) corrigée(s): 11.0.0 (Merge et Maintenance)

Type: Nouvelle fonctionnalité Priorité: Mineur
Rapporteur: Richard Dubois Attribution: Richard Dubois
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word abandonnistes-questionnaire-nvs_291106.doc     File Planning_abandonniste_questionnaire_v0.2_light.mpp    
Pays:
FRA - France
Site: Prod
Projets PM archivés: Abandonnistes

 Description   
Bonjour,

Le projet "Abandonnistes" est lancée !

Vous trouverez en pièce jointe une "mini spéc" (sur la base du doc de point d'entrée d'ALV) et une planning prévisonnel.

Bonne journée @ tous

 Commentaires   
Commentaire de Younès Charrière [ 29/nov./06 15:06 ]
Passera post déploiement.
Commentaire de Richard Dubois [ 29/nov./06 15:50 ]
Bonjour,

Les libellés et les messages d'erreurs viennent d'être "franchisé".

Rendez-vous sur

http://websurveyor.net/wsb.dll/72568/enquete_priceminister.htm

pour tester et avoir vos retours

Bons tests :)
Commentaire de Richard Dubois [ 30/nov./06 16:26 ]
Alex,

concernant l'extraction des données BI, quels sont les champs dont tu aurais besoin ??

Avec Agathe, on a dèjà pensé à:

user_id
pseudo
email

En vois-tu d'autres ??

Bonne fin de journée
Commentaire de Alexandra Viravaud [ 30/nov./06 18:00 ]
non ca me parait bien.
Commentaire de Richard Dubois [ 01/déc./06 09:04 ]
Alexandra bonjour,


Pour l'envoi avec Email Vision:

1 - Est-ce que la créa de la newsletter est prête ?

2- J'ai enfin la solution pour pouvoir recupérer l'id_user dans Websurveyor !

l'url que tu devras rajouter dans le mail sera de type

http://websurveyor.net/wsb.dll/72568/enquete_priceminister.htm?WSB16=[user_ID]

[user_ID] te sera fourni par Agathe

Comme cela l'internaute reçoit le mail, il clique sur le lien (qui l'identifie aussi grace au user_ID) pour répondre au questionnaire.

Lorsque via Websurveyor tu feras ton analyse, a l'extraction des données (soit au format txt ou csv), pour chaque ligne, tu auras donc un user_id qui te permettra de savoir qui a répondu.

@ta dispo pour plus d'informations

Bonne journée

Commentaire de Alexandra Viravaud [ 01/déc./06 10:38 ]
la créa sera en principe prête ce soir.
Alex
Commentaire de Younès Charrière [ 11/déc./06 18:04 ]
Les tests étaient concluants. Richard, peux tu résoudre ce jira si tout va bien de ton côté ?
Commentaire de Richard Dubois [ 12/déc./06 09:33 ]
L'equête est en ligne ! De bons retours, une mine d'information (beaucoup de commentaires pertinents). Merci à tous !




[EXP-2730] phaeton : reduire l'occupation des disques Création: 27/sept./06 14:46  Mise à jour: 25/juin/07 18:59  Résolue: 31/oct./06 11:48

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Justin Ziegler Attribution: Patrice Boulanger
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Voici ce qui sort d'une analyse de l'occupation disque de /data sur phaeton :

Extrait de la commande "du -ks" :
 
4712 asconf
2992 sudmannm
1540 tmp.edouard
3008 grehalln
3412 tmp_gak

38580 jos
46976 klosekg
80728 pm_archpurge
80240 decpool
 
130 988 cnet
110 140 pmftpstock
170 748 pmfiletransfers
219 880 tmp
444 500 pmproductimport


 
cnet :
ne contient que de vieux fichiers !!! peut on le supprimer ? A voir avec Edouard ? peut on le comprimer ?
 
tmp :
j'ai l'impression que plein de choses peuvent etre supprimes
 
tmp.edouard :
on peut le virer ? A voir avec Edouard.
 
decpool :
demander au decisionnel de faire du menage ?
 
/data/priceminister/pmproductimport/titelive_images
/data/priceminister/pmproductimport/titelive
/data/priceminister/pmproductimport/tf1video
=> peut bientot etre supprimé ?



 Commentaires   
Commentaire de Patrice Boulanger [ 27/sept./06 15:00 ]
Etat initial:

/dev/cciss/c0d0p7 13268456 9064472 3529972 72% /data

Commentaire de Patrice Boulanger [ 27/sept./06 15:01 ]
Répertoire jos/:

[adminpm@phaeton jos]$ ll
total 38588
drwxrwxr-x 2 adminpm adminpm 4096 Dec 7 2005 .
drwxr-xr-x 37 adminpm adminpm 8192 Sep 27 14:56 ..
-rw-r--r-- 1 adminpm adminpm 13521 Nov 23 2005 log4j.xml
-rw-r--r-- 1 adminpm adminpm 14369 Nov 23 2005 log4j.xml.20051123
-rw-r--r-- 1 adminpm adminpm 1272612 Dec 7 2005 NMCE.tgz
-rw-rw-r-- 1 adminpm adminpm 38144308 Nov 24 2005 queryTxn.log.20051122.1151.gz

Fichiers de logs de presque 1 an => supprimés.
Commentaire de Patrice Boulanger [ 27/sept./06 15:02 ]
pour decpool j'ai demandé à Agathe de me donner un état.
Commentaire de Patrice Boulanger [ 27/sept./06 15:09 ]
Je propose aussi de cleaner le répertoire /data/mrtg:

[adminpm@phaeton mrtg]$ du -sh *
4.0K cron.mrtg
4.0K cron.scr
1.2M etc
19M livraison
0 minitord
1.8M minitord-0.11.10
1.8M minitord-0.12.4
1.8M minitord-0.12.6
1.8M minitord-0.12.7
6.3M minitord.orig
1.3M perl
4.0K profile.rc
5.1M tmp
11M var

En particulier, les anciennes versions de minitord:

[adminpm@phaeton mrtg]$ cd livraison/
[adminpm@phaeton livraison]$ ll
total 19256
drwxrwxr-x 2 mrtg adminpm 4096 Jun 30 14:40 .
drwxr-xr-x 14 mrtg adminpm 4096 Jun 30 14:42 ..
-rw-rw-r-- 1 mrtg adminpm 79230 Aug 18 2005 minitord-0.0.15.tar.gz
-rw-r--r-- 1 mrtg adminpm 89267 Aug 12 2005 minitord-0.0.21.tar.gz
-rw-r--r-- 1 mrtg adminpm 89542 Aug 19 2005 minitord-0.0.27.tar.gz
-rw-r--r-- 1 mrtg adminpm 96562 Aug 24 2005 minitord-0.0.28.tar.gz
-rw-r--r-- 1 mrtg adminpm 110220 Aug 26 2005 minitord-0.0.29.tar.gz
-rw-r--r-- 1 mrtg adminpm 110970 Aug 31 2005 minitord-0.0.30.tar.gz
-rw-r--r-- 1 mrtg adminpm 166307 May 5 11:09 minitord-0.10.1.tar.gz
-rw-r--r-- 1 mrtg adminpm 166331 May 9 11:55 minitord-0.10.2.tar.gz
-rw-r--r-- 1 mrtg adminpm 167070 May 10 17:48 minitord-0.10.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 167210 May 12 11:45 minitord-0.10.4.tar.gz
-rw-r--r-- 1 mrtg adminpm 167705 May 12 14:26 minitord-0.10.5.tar.gz
-rw-r--r-- 1 mrtg adminpm 167700 May 12 14:37 minitord-0.10.6.tar.gz
-rw-r--r-- 1 mrtg adminpm 161791 Nov 22 2005 minitord-0.1.10.tar.gz
-rw-r--r-- 1 mrtg adminpm 169664 Jun 12 10:42 minitord-0.11.10.tar.gz
-rw-r--r-- 1 mrtg adminpm 156429 Nov 24 2005 minitord-0.1.11.tar.gz
-rw-r--r-- 1 mrtg adminpm 167702 May 12 14:40 minitord-0.11.1.tar.gz
-rw-r--r-- 1 mrtg adminpm 156438 Nov 24 2005 minitord-0.1.12.tar.gz
-rw-r--r-- 1 mrtg adminpm 167722 May 12 15:31 minitord-0.11.2.tar.gz
-rw-r--r-- 1 mrtg adminpm 156451 Nov 24 2005 minitord-0.1.13.tar.gz
-rw-r--r-- 1 mrtg adminpm 168086 May 15 15:02 minitord-0.11.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 227000 Nov 29 2005 minitord-0.1.14.tar.gz
-rw-r--r-- 1 mrtg adminpm 168110 May 16 10:40 minitord-0.11.4.tar.gz
-rw-r--r-- 1 mrtg adminpm 226778 Nov 29 2005 minitord-0.1.15.tar.gz
-rw-r--r-- 1 mrtg adminpm 168588 May 17 16:28 minitord-0.11.5.tar.gz
-rw-r--r-- 1 mrtg adminpm 169503 Jun 5 15:15 minitord-0.11.6.tar.gz
-rw-r--r-- 1 mrtg adminpm 210641 Dec 2 2005 minitord-0.1.17.tar.gz
-rw-r--r-- 1 mrtg adminpm 169532 Jun 5 17:15 minitord-0.11.7.tar.gz
-rw-r--r-- 1 mrtg adminpm 203768 Dec 2 2005 minitord-0.1.18.tar.gz
-rw-r--r-- 1 mrtg adminpm 169532 Jun 6 11:19 minitord-0.11.8.tar.gz
-rw-r--r-- 1 mrtg adminpm 203792 Dec 19 2005 minitord-0.1.19.tar.gz
-rw-r--r-- 1 mrtg adminpm 169527 Jun 7 11:25 minitord-0.11.9.tar.gz
-rw-r--r-- 1 mrtg adminpm 121387 Sep 12 2005 minitord-0.1.1.tar.gz
-rw-r--r-- 1 mrtg adminpm 204099 Dec 19 2005 minitord-0.1.20.tar.gz
-rw-r--r-- 1 mrtg adminpm 206808 Dec 19 2005 minitord-0.1.21.tar.gz
-rw-r--r-- 1 mrtg adminpm 170343 Jun 14 10:35 minitord-0.12.1.tar.gz
-rw-r--r-- 1 mrtg adminpm 207353 Dec 22 2005 minitord-0.1.22.tar.gz
-rw-r--r-- 1 mrtg adminpm 170366 Jun 15 10:44 minitord-0.12.2.tar.gz
-rw-r--r-- 1 mrtg adminpm 209313 Dec 23 2005 minitord-0.1.23.tar.gz
-rw-r--r-- 1 mrtg adminpm 170372 Jun 19 14:28 minitord-0.12.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 209346 Dec 26 2005 minitord-0.1.24.tar.gz
-rw-r--r-- 1 mrtg adminpm 170332 Jun 21 11:18 minitord-0.12.4.tar.gz
-rw-r--r-- 1 mrtg adminpm 171253 Jun 22 10:44 minitord-0.12.5.tar.gz
-rw-r--r-- 1 mrtg adminpm 209611 Dec 26 2005 minitord-0.1.26.tar.gz
-rw-r--r-- 1 mrtg adminpm 171177 Jun 26 10:04 minitord-0.12.6.tar.gz
-rw-r--r-- 1 mrtg adminpm 210595 Dec 28 2005 minitord-0.1.27.tar.gz
-rw-r--r-- 1 mrtg adminpm 172171 Jun 30 14:42 minitord-0.12.7.tar.gz
-rw-r--r-- 1 mrtg adminpm 210594 Dec 28 2005 minitord-0.1.29.tar.gz
-rw-r--r-- 1 mrtg adminpm 120882 Oct 5 2005 minitord-0.1.2.tar.gz
-rw-r--r-- 1 mrtg adminpm 210630 Dec 28 2005 minitord-0.1.30.tar.gz
-rw-r--r-- 1 mrtg adminpm 210637 Jan 2 2006 minitord-0.1.31.tar.gz
-rw-r--r-- 1 mrtg adminpm 212790 Jan 4 2006 minitord-0.1.32.tar.gz
-rw-r--r-- 1 mrtg adminpm 213826 Jan 4 2006 minitord-0.1.33.tar.gz
-rw-r--r-- 1 mrtg adminpm 220056 Jan 9 2006 minitord-0.1.34.tar.gz
-rw-r--r-- 1 mrtg adminpm 225323 Jan 16 2006 minitord-0.1.36.tar.gz
-rw-r--r-- 1 mrtg adminpm 129737 Oct 11 2005 minitord-0.1.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 136457 Oct 18 2005 minitord-0.1.4.tar.gz
-rw-r--r-- 1 mrtg adminpm 131940 Oct 19 2005 minitord-0.1.5.tar.gz
-rw-rw-r-- 1 mrtg adminpm 137078 Nov 17 2005 minitord-0.1.8.tar.gz
-rw-r--r-- 1 mrtg adminpm 195930 Jan 19 2006 minitord-0.2.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 195939 Jan 19 2006 minitord-0.2.4.tar.gz
-rw-r--r-- 1 mrtg adminpm 196950 Jan 20 2006 minitord-0.2.5.tar.gz
-rw-r--r-- 1 mrtg adminpm 196911 Jan 20 2006 minitord-0.2.6.tar.gz
-rw-r--r-- 1 mrtg adminpm 196932 Jan 20 2006 minitord-0.2.7.tar.gz
-rw-r--r-- 1 mrtg adminpm 196825 Jan 30 2006 minitord-0.2.8.tar.gz
-rw-r--r-- 1 mrtg adminpm 197195 Jan 30 2006 minitord-0.3.1.tar.gz
-rw-r--r-- 1 mrtg adminpm 184214 Jan 30 2006 minitord-0.3.2.tar.gz
-rw-r--r-- 1 mrtg adminpm 184255 Jan 30 2006 minitord-0.3.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 184270 Jan 30 2006 minitord-0.3.4.tar.gz
-rw-r--r-- 1 mrtg adminpm 192750 Feb 2 2006 minitord-0.3.5.tar.gz
-rw-r--r-- 1 mrtg adminpm 134149 Feb 3 2006 minitord-0.3.7.tar.gz
-rw-r--r-- 1 mrtg adminpm 132712 Feb 6 2006 minitord-0.4.0.tar.gz
-rw-r--r-- 1 mrtg adminpm 136622 Feb 13 2006 minitord-0.4.10.tar.gz
-rw-r--r-- 1 mrtg adminpm 132681 Feb 6 2006 minitord-0.4.1.tar.gz
-rw-r--r-- 1 mrtg adminpm 132674 Feb 6 2006 minitord-0.4.2.tar.gz
-rw-r--r-- 1 mrtg adminpm 132679 Feb 6 2006 minitord-0.4.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 132685 Feb 6 2006 minitord-0.4.5.tar.gz
-rw-r--r-- 1 mrtg adminpm 135544 Feb 8 2006 minitord-0.4.6.tar.gz
-rw-r--r-- 1 mrtg adminpm 136848 Feb 8 2006 minitord-0.4.7.tar.gz
-rw-r--r-- 1 mrtg adminpm 144831 Feb 20 2006 minitord-0.5.0.tar.gz
-rw-r--r-- 1 mrtg adminpm 146873 Feb 22 2006 minitord-0.6.0.tar.gz
-rw-r--r-- 1 mrtg adminpm 147290 Feb 22 2006 minitord-0.6.1.tar.gz
-rw-r--r-- 1 mrtg adminpm 147628 Feb 23 2006 minitord-0.6.2.tar.gz
-rw-r--r-- 1 mrtg adminpm 147907 Mar 6 2006 minitord-0.6.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 148496 Mar 6 2006 minitord-0.6.4.tar.gz
-rw-r--r-- 1 mrtg adminpm 148736 Mar 8 2006 minitord-0.6.5.tar.gz
-rw-r--r-- 1 mrtg adminpm 155011 Apr 3 17:18 minitord-0.7.10.tar.gz
-rw-r--r-- 1 mrtg adminpm 154995 Apr 5 15:40 minitord-0.7.11.tar.gz
-rw-r--r-- 1 mrtg adminpm 155168 Apr 6 10:49 minitord-0.7.12.tar.gz
-rw-r--r-- 1 mrtg adminpm 152055 Mar 20 2006 minitord-0.7.2.tar.gz
-rw-r--r-- 1 mrtg adminpm 153337 Mar 28 2006 minitord-0.7.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 153342 Mar 28 2006 minitord-0.7.4.tar.gz
-rw-r--r-- 1 mrtg adminpm 153363 Mar 28 2006 minitord-0.7.5.tar.gz
-rw-r--r-- 1 mrtg adminpm 153881 Mar 30 12:41 minitord-0.7.6.tar.gz
-rw-r--r-- 1 mrtg adminpm 154703 Mar 31 11:50 minitord-0.7.7.tar.gz
-rw-r--r-- 1 mrtg adminpm 154984 Apr 3 15:39 minitord-0.7.8.tar.gz
-rw-r--r-- 1 mrtg adminpm 155018 Apr 3 16:19 minitord-0.7.9.tar.gz
-rw-r--r-- 1 mrtg adminpm 155170 Apr 6 11:42 minitord-0.8.0.tar.gz
-rw-r--r-- 1 mrtg adminpm 155544 Apr 6 14:22 minitord-0.8.1.tar.gz
-rw-r--r-- 1 mrtg adminpm 156246 Apr 7 12:26 minitord-0.8.2.tar.gz
-rw-r--r-- 1 mrtg adminpm 157422 Apr 11 10:54 minitord-0.8.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 157468 Apr 11 11:41 minitord-0.8.4.tar.gz
-rw-r--r-- 1 mrtg adminpm 157526 Apr 11 12:01 minitord-0.8.5.tar.gz
-rw-r--r-- 1 mrtg adminpm 157492 Apr 11 16:41 minitord-0.8.6.tar.gz
-rw-r--r-- 1 mrtg adminpm 158757 Apr 14 15:11 minitord-0.9.0.tar.gz
-rw-r--r-- 1 mrtg adminpm 166130 May 3 11:03 minitord-0.9.10.tar.gz
-rw-r--r-- 1 mrtg adminpm 166258 May 4 16:08 minitord-0.9.11.tar.gz
-rw-r--r-- 1 mrtg adminpm 166265 May 4 17:49 minitord-0.9.12.tar.gz
-rw-r--r-- 1 mrtg adminpm 159370 Apr 14 17:42 minitord-0.9.2.tar.gz
-rw-r--r-- 1 mrtg adminpm 159501 Apr 19 16:50 minitord-0.9.3.tar.gz
-rw-r--r-- 1 mrtg adminpm 159955 Apr 19 17:38 minitord-0.9.4.tar.gz
-rw-r--r-- 1 mrtg adminpm 159968 Apr 19 18:29 minitord-0.9.5.tar.gz
-rw-r--r-- 1 mrtg adminpm 160933 Apr 24 15:31 minitord-0.9.6.tar.gz
-rw-r--r-- 1 mrtg adminpm 160991 Apr 26 17:56 minitord-0.9.7.tar.gz
-rw-r--r-- 1 mrtg adminpm 161297 Apr 28 14:19 minitord-0.9.8.tar.gz
-rw-r--r-- 1 mrtg adminpm 164770 May 3 10:48 minitord-0.9.9.tar.gz
Commentaire de Patrice Boulanger [ 27/sept./06 15:14 ]
tmp.edouard et cnet => mail à Edouard.

Pour decpool, le BI met des fichiers importants pour eux dans ce répertoire. Vu avec Agathe pour faire le ménage et peut-être déplacer le contenu (sur tellus, latone, titan ?)
Commentaire de Patrice Boulanger [ 27/sept./06 15:16 ]
Pour /data/priceminister/klosekg, mail envoyé à Gaël.
Commentaire de Patrice Boulanger [ 28/sept./06 14:36 ]
Les répertoires jos, klosekg et decpool ont été vidés.
Commentaire de Justin Ziegler [ 28/sept./06 16:43 ]
Cool !
Quelle est le prochain candidat ?
Commentaire de Patrice Boulanger [ 31/oct./06 11:48 ]
L'espace disque utilisé sur /data sur phaeton est descendu à 56%.

Nous avons supprimé les anciennes versions du contenu statique de l'application.




[DEC-511] intégration des nouveaux contacts et requalification de la BDD PM suite au jeu "mission super vendeur" Création: 30/nov./06 14:50  Mise à jour: 14/sept./07 15:25  Résolue: 16/janv./07 15:09

Etat: Fermé
Projet: Reporting
Composants: Partners
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Bloquant
Rapporteur: Thomas Beylot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel tablecorrespondance.xls    
Liens des demandes:
Duplicate
doublon de DEC-482 fin de jeu super vendeur Fermé
Pays:
FRA - France

 Description   
Le jeu super vendeur se finit le 29/12.

A l'issue de ce jeu il faudra attribuer les chances supplémentaires au joueurs ayant déposé une annonce lors du jeu (ceci fait l'objet d'un autre jira) et aussi intégrer les nouveaux contacts suite au jeu et actualiser le profil des pricemembers.

Pour être au point il faudrait bien checker la forme du fichier que 1000 mercis m'enverrait ?


merci !

thomas.

 Commentaires   
Commentaire de Agathe Remy [ 01/déc./06 16:20 ]
Thomas,

Voici le format du fichier que doit nous fournir 1000Mercis: fichier CSV (séparateur ";")
email;nom;prenom;adresse1;adresse2;cp;ville;pays;IS_PARTNER_SUBSCRIBER;IS_CULTURAL_SUBSCRIBER;IS_HIGHTECH_SUBSCRIBER;IS_HOUSE_SUBSCRIBER

Cordialement,
Agathe
Commentaire de Edouard Laurent [ 04/déc./06 13:43 ]
email;prenom;nom;IS_CULTURAL_SUB;TRACKING_ID;;;IS_PARTNER_SUB;IS_HIGHTECH_SUB;IS_HOUSE_SUB

Le format du fichier devrait plutot ressembler a ca

Merci
Edouard
Commentaire de Thomas Beylot [ 09/janv./07 12:20 ]
je viens de demander le bon format pour le fichier à 1000mercis.

en attendant je vais de ce pas attacher la table de correspondance à ce jira.


thomas.
Commentaire de Edouard Laurent [ 16/janv./07 15:09 ]
L'integration est terminé : 161 874 nouveaux contacts dans le cadre de ce jeu
Commentaire de Thomas Beylot [ 16/janv./07 16:21 ]
une ptite question pour finir:
sais-tu combien de ces contacts sont opt-in ?
Commentaire de Edouard Laurent [ 16/janv./07 16:26 ]
C'est plutot une demande BI, essaye de voir ca avec Agathe




[BIN-242] [Finance] : écart Titan / BO sur mouvements PMV Création: 11/déc./06 14:36  Mise à jour: 07/janv./08 18:09  Résolue: 02/janv./08 11:53

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Philippe Favrot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

écart entre les chiffres issus de Titan (operation report) et BO (Daily mvt PMV) pour la journée du 24 novembre concernant le type de mouvement "Credit_BO" :
   Titan : 11 715,21 euros
   BO : 12 722,42 euros

Philippe

 Commentaires   
Commentaire de Agathe Remy [ 14/déc./06 12:22 ]
En effet, dans le rapport de Titan ne sont pas prise en comptes les opérations non associés à une cause :
2006/11/24;CREDIT_BO;;1007,21
2006/11/24;CREDIT_BO;Cashstore;84,2
2006/11/24;CREDIT_BO;Remboursement;11225,36
2006/11/24;CREDIT_BO;autre crédit;364,35
2006/11/24;CREDIT_BO;Chèque retourné;41,3

Le différence correspond donc au montant des opérations sans cause.

Cordialement,
Agathe
Commentaire de Philippe Favrot [ 15/déc./06 14:49 ]
Agathe,
tu peux m'en dire plus sur ces 1 007,21 euros de crédit PM sans cause : détail par pseudo...
En fait ce serait la première fois que ce cas de figure se produit puisque jusqu'alors il n'y a jamais eu d'écart Titan / BO.
Merci
Philippe
Commentaire de Agathe Remy [ 15/déc./06 15:36 ]
Il s'agit d'une operation unique : 10552

En fait, jusqu'au 25 juin 2004 les opérations n'avaient pas de causes associées. A partir du 28/06/2004, toutes les opérations sont associées à une cause.

L'opération 10552 a été créée le 08/11/2002 pour le user account id 458071 et a été modifiée le 24/11/2006. En revanche, je n'ai aucun moyen de savoir en quoi a consisté la modification du 24 novembre dernier : il n'y a aucun évènement associé.

Cordialement,
Agathe
Commentaire de Philippe Favrot [ 19/déc./06 11:50 ]
Agathe,
en fait, aucun commentaire n'était renseigné au niveau de ce mouvement du 08/11/2002 donc on ne savait pas ce que c'était.
Steven a donc ajouté un commentaire en date du 24/11/2006 ; en revanche il n'y a eu aucune modification de la date de finalisation de ce mouvement. Donc l'ajout de ce commentaire aurait du n'avoir aucun impact sur le rapport détaillant les mouvements affectant les PMV : or on constate que :
- les mouvements du 08/11/02 (credit_BO) sont maintenant de 54,20 ¿ vs 1 061,41 ¿ avant la modif ;
- les mouvements du 24/11/06 (credit_BO) reprennent cette opération.
Il doit donc y avoir un problème sur les dates retenues pour élaborer ce rapport. Peux tu vérifier.
Merci
Philippe
Commentaire de Agathe Remy [ 21/déc./06 11:26 ]
Philippe,

Dans le rapport que tu as défini avec MEZ, vous vous basez sur la change date de l'opération, donc sa date de dernière mise à jour. Je pense qu'il aurait fallu se baser sur la date de création du mouvement. Mais cela fait partie des sujets que je voulais aborder avec toi lors de notre point sur le BI Espagne cet aprem.

Cordialement,
Agathe
Commentaire de Agathe Remy [ 03/août/07 17:16 ]
Philippe,

Peut-on fermer ce JIRA?

Merci:-)
Agathe
Commentaire de Agathe Remy [ 02/janv./08 11:53 ]
Philippe,

Peut-on fermer ce JIRA?

Merci:-)

Agathe
Commentaire de Philippe Favrot [ 07/janv./08 17:32 ]
Agathe,
tu peux effectivement fermer ce Jira.
Merci :-)
Philippe




[BIN-425] [BackOffice] : Filtre Commit-Closing<1 (univers item) Création: 01/avr./08 16:08  Mise à jour: 23/avr./08 10:18  Résolue: 21/avr./08 15:05

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Florian Ambrosi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
FRA - France

 Description   
J'aurais bien eu besoin de ce petit filtre pour etayer nos rapports de transactions entre comptes.
Par contre j'ai l'impression qu'il ne fonctionne pas correctement puisqu'il me retourne des articles dont le délai entre les statut committed et closed est de plus d'1 jour.

Est-ce que ce ne serait pas plutot CLOSING DATE - COMMIT DATE dans la requete ?

Merci.

 Commentaires   
Commentaire de Agathe Remy [ 01/avr./08 16:12 ]
Bonjour Cédric,

Peux-tu me donner le nom exact et le chemin d'accès du rapport dont il s'agit?

Merci.
Agathe
Commentaire de Cedric Favero [ 01/avr./08 16:17 ]
C'est un rapport que je suis en train de faire

Dans Favoris\Cedric "Fraudes transactions vendeur/acheteur" , ma requete 10
Commentaire de Agathe Remy [ 15/avr./08 12:20 ]
Bonjour Cédric,

Peux-tu me donner un exemple d'article renvoyé par la requête qui te semble ne pas correspondre au critère de sélection?

Sinon, pour information, les dates stockées dans BI sont arrondies au jour et ne stockent pas les heures, minutes et secondes (pour des questions de volumétrie). Ainsi, la date de confirmation du vendeur stockée dans BI sera le 15/04/2008 00h00mn00sec que le vendeur ait confirmé la vente à 01h01mn01sec ou 23h59mn59sec.
Ainsi, faire un filtre pour évaluer un délai inférieur à 1 jour ne me semble par pertinent avec de telles données (sans le détail des heures, minutes et secondes).

Si le besoin est fort, nous pouvons mettre à jour ces dates afin d'intégrer les heures, minutes et secondes, mais pour cela, il nous faut une justification business parce que cette évolution demande plusieurs jours de développement.

Cordialement,
Agathe


Commentaire de Cedric Favero [ 15/avr./08 14:32 ]
voici la requete telle qu'est faite (cf capture)
Commentaire de Cedric Favero [ 15/avr./08 14:38 ]
etr si on prend certains articles retournés, il ne remplissent pas la condition 1 jour maxi entre les états committed et closed

ex des premiers articles retournés:
http://bo.priceminister.com/purchase_back?action=itemview&itemid=79533326
http://bo.priceminister.com/purchase_back?action=itemview&itemid=79534362
Commentaire de Cedric Favero [ 15/avr./08 14:41 ]
je n'ai pas besoin des heures , minutes , secondes :-)
Commentaire de Agathe Remy [ 15/avr./08 15:26 ]
Après mure réflexion, le problème vient du fait que ta condition est construite à l'envers?!
En effet, la date de confirmation du vendeur étant toujours antérieure à la date de clôture de l'article, leur différence est toujours négative donc inférieure à 1 jour...
Cette condition prédéfinie est donc erronées.
Je le fait donc corriger.

Agathe
Commentaire de Cedric Favero [ 15/avr./08 15:31 ]
c'est pour çà que je disais , n'est-ce pas plutot:?:

CLOSING DATE moins COMMIT DATE inferiieure à 1
Commentaire de Cedric Favero [ 22/avr./08 09:55 ]
Je ne vois pas le filtre modifié dans l'univers Purchase. Il est où?
Le commit-closing<1 n'a pas changé.
Merci.
Commentaire de Agathe Remy [ 22/avr./08 10:00 ]
Cédric,

La modification a été apportée pour l'instant en Développement (d'où le nom de l'univers "DEV - ITEM" signalé par Florian).
Après validation, nous passerons la modification en Production.

Agathe
Commentaire de Cedric Favero [ 22/avr./08 10:05 ]
Ok dac, contraitement aux APP , çà ne m'apparaissait pas clairement , avec une version cible et tout..
Merci.
Commentaire de Florian Ambrosi [ 22/avr./08 17:39 ]
Agathe,

C'est déployé sur le serveur en production.

Florian
Commentaire de Cedric Favero [ 23/avr./08 10:14 ]
C'est bon, çà marche nickel.
Merci.




[EXP-4215] [Espagne] : Demande de rapport : valeur client par tracking Espagne Création: 01/févr./08 12:31  Mise à jour: 25/juin/08 17:29  Résolue: 25/juin/08 17:29

Etat: Résolu
Projet: Exploitation
Composants: Rapport
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Charles Decaux Attribution: Patrick Pereira
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne

 Description   
Bonjour,

L'indicateur principal des partenariats est aujourd'hui le coût d'acquisition client sur l'Espagne
Afin de déterminer si les nouveaux clients sont "rentables" on souhaite connaître la valeur client par tracking.

Il nous faudrait donc un rapport indiquant, par tracking et par groupe de tracking la valeur client sur les 6 derniers mois et sur les 12 derniers mois.

Merci

Charles

 Commentaires   
Commentaire de Agathe Remy [ 05/févr./08 15:07 ]
Charles,

Peux-tu nous donner le chemin d'accès dans l'intranet du ou des rapports BI ou titan au(x)quel(s) tu fait allusion?

Merci:-)

Agathe
Commentaire de Charles Decaux [ 05/févr./08 17:03 ]
http://intra.priceminister.com/stats/reports/confid/Suivi_Acheteurs/
Commentaire de Agathe Remy [ 07/févr./08 10:19 ]
Patrick,

Comme convenu, je te réattribue ce JIRA. A voir s'il vraiment nécessaire de produire ces rapports.

Les requêtes de génération des rapports sur titan sont les suivantes :
/data/priceminister/reporting/platform/prod/sql/sources/executive/report_suivi_acheteurs.sql
/data/priceminister/reporting/platform/prod/sql/sources/executive/report_premier_achat_avec_coupon.sql
/data/priceminister/reporting/platform/prod/sql/sources/executive/report_premier_achat_sans_coupon.sql
/data/priceminister/reporting/platform/prod/sql/sources/executive/report_premier_achat_non_vendeur.sql
/data/priceminister/reporting/platform/prod/sql/sources/executive/report_premier_achat_vendeur.sql

Pour se générer, ces rapports utilisent une vue matérialisée dont tu trouveras le script également sur titan : /u01/priceminister/priceminister/reporting/oneshot/Executive/new_buyer_mv.sql

Agathe
Commentaire de Agathe Remy [ 07/févr./08 10:21 ]
Charles,

Ces rapports constituent ce que nous appelons la life time value. En revanche, en aucun cas ils ne donnent d'information par tracking ou groupe de tracking. Es-tu sûr qu'il s'agit de ces rapports?

Agathe
Commentaire de Charles Decaux [ 08/févr./08 09:39 ]
Effectivement, cela ne correspond pas à ce que je souhaite.
Cependant cela peut me servir pour calculer la LTV globale, indépendemment du tracking.
C'est déjà ca.

Merci :-)
Commentaire de Patrick Pereira [ 13/févr./08 16:12 ]
Mettre en place les rapports sur l'Espagne signifie une charge de travail pour moi et pour la base.
Si ces rapports n'ont pas une réelle utilité, autant ne pas le faire.
Pourriez-vous clairement identifier vos réels besoin ?
Merci.




Mise en oeuvre EVANDRE (EXP-3568)

[EXP-3603] Preparation tableau correspondance vh-@IP Création: 23/mai/07 11:14  Mise à jour: 25/juin/07 19:01  Résolue: 05/juin/07 17:35

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Mineur
Rapporteur: Jérémie Bennejean Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel correspondance.xls    
Pays:
FRA - France

 Commentaires   
Commentaire de Jérémie Bennejean [ 31/mai/07 10:31 ]
FRANCE WWW
<VirtualHost 212.23.167.30:80>
    ServerName www.priceminister.com:80

ESPAGNE WWW

<VirtualHost 212.23.167.36:80>
    DocumentRoot "/usr/local/apache/es/htdocs/pmweb/www.priceminister.es"
    ServerName www.priceminister.es:80
Commentaire de Jérémie Bennejean [ 31/mai/07 10:49 ]
Note pour moi, penser à demander à Jet de completer le /etc/hosts de evandre avec :

212.23.167.31 ofup.priceminister.com
212.23.167.31 virginmega.priceminister.com
212.23.167.31 m6net.priceminister.com
212.23.167.31 m6.priceminister.com
212.23.167.31 m6music.priceminister.com
212.23.167.31 m6game.priceminister.com
212.23.167.31 cinenow.priceminister.com
212.23.167.31 francemobiles.priceminister.com
212.23.167.31 jeuxvideo.priceminister.com
212.23.167.31 preview.priceminister.com
212.23.167.31 rfm.priceminister.com
212.23.167.31 freesurf.priceminister.com
212.23.167.31 croix-rouge.priceminister.com www.croix-rouge.priceminister.com
212.23.167.31 tiscalibe.priceminister.com
212.23.167.31 test.priceminister.com
212.23.167.31 europe2.priceminister.com
212.23.167.31 epik.priceminister.com
212.23.167.33 bo.priceminister.com bi.priceminister.com eglue.priceminister.com ig.priceminister.com
212.23.167.31 koobuycity.priceminister.com
212.23.167.31 mobilokaz.priceminister.com
212.23.167.35 www.radindesbois.com
212.23.167.37 pcdoccasions.vnunet.fr
212.23.167.32 occasion.camif.fr
212.23.167.34 occasion.presence-pc.com
212.23.167.31 mobilesachat.priceminister.com
212.23.167.38 bambinoccasion.priceminister.com
212.23.167.39 occasion.rueducommerce.fr occasion.rueducommerce.com
212.23.167.43 occasion.liberation.fr
212.23.167.36 www.priceminister.es
212.23.167.46 demo.priceminister.es
212.23.167.44 preview.priceminister.es
212.23.167.45 bo.priceminister.es
212.23.167.31 lycos-occasion.priceminister.com
212.23.167.31 laredoute-occasion.priceminister.com
212.23.167.31 journauxdumidi.priceminister.com
212.23.167.31 sfr.priceminister.com
212.23.167.31 nicematin.priceminister.com




[DEC-599] bug sur les rapports SLTV Création: 11/juin/07 16:20  Mise à jour: 04/sept./08 14:57  Résolue: 04/sept./08 14:57

Etat: Fermé
Projet: Reporting
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Thomas Beylot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Quand on regarde de plus près les stats données par le rapport home/oracle/task_force_vendeur/tfv_2007-05/SLTV_ADVERT_2007-05.csv (mais aussi home/oracle/task_force_vendeur/tfv_2007-05/SLTV_SALES_2007-05.csv ) on se rend compte que le rapport fait état de 5 347 nouveaux vendeurs pour 37 303 annonces.

Toutes les datas pour la promo de mai 07 ont l'air erronées, donc... :-(

De plus quand on regarde dans le BO on voit que:
- au 1er mai 2007 : 461971
- au 31 mai 2007 : 480276

soient 18 305 nouveaux vendeurs... ce qui semble plus logique quand regarde les chiffres précédents (16 000 en avril, 20 000 en mars)...

Il doit donc s'être passé quelque chose ?


thomas



 Commentaires   
Commentaire de Agathe Remy [ 04/sept./08 14:57 ]
Suite au transfert des rapports SLTV dans BI, je ferme ce JIRA qui n'a plus lieu d'être...

Agathe




[APP-17620] Annonce auto frauduleuse visible par " articles mémorisées" Création: 23/août/07 14:54  Mise à jour: 29/oct./09 10:05  Résolue: 26/oct./09 12:20

Etat: Fermé
Projet: Application PriceMinister
Composants: Auto (Statistiques)
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 56.0.0 (TX-J)

Type: Bogue Priorité: Majeur
Rapporteur: Cedric Favero Attribution: Emeric Teil
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à APP-16234 Annonce auto frauduleuse en ligne alo... Fermé
Pays:
FRA - France
Classif1: BP
Classif2: auto
Projets PM archivés: AUTO : Nettoyage

 Description   
Un utilisateur (carrie19) me signale une annonce frauduleuse au 21/08

Problème: l'annonce est périmée et le vendeur est en -2 depuis le 07/03/2007.

Apparemment il est passé par articles mémorisés où l'annonce est toujours visible , il peut meme envoyer des messages au vendeur.

Celà commence à etre vraiment dangereux ces problèmes de visibilité auto.


 Commentaires   
Commentaire de Cedric Favero [ 24/août/07 09:53 ]
Autre cas pour exemple.

Pseudo: drmisti ( Roumain)

Son compte est en -2 depuis le 19/12/2006 et on nous signale aujourd'hui son annonce.
Encore une fois elle était dans les articles mémorisés d'un acheteur (pseudo: topexpo)
Commentaire de Emeric Teil [ 10/déc./07 10:09 ]
Du côté des "transactions", on a réalisé certaines modifications sur le fonctionnement de la visibilité des annonces auto.
Ainsi, lors de la création de l'annonce, la visibilité du vendeur est prise en compte (reportée sur l'annonce), ce qui n'était pas le cas auparavant (la visibilité de l'annonce dépendait uniquement de la conf produit).

En complément à ces corrections, il reste certains dysfonctionnements à corriger, dont celui lié à ce JIRA. Ainsi, dans le cadre de l'Auto :

-> Les coordonnées du vendeur sont liées à la fiche produit complément (et non pas uniquement à l'annonce)
-> On affiche en Front la fiche produit complément (et non pas uniquement FP + DA)
-> Les articles mémorisés ne portent pas sur les fiches produits mais sur les fiches produits compléments

Sur le reste du site, lorsqu'un vendeur est passé en visibilité -2 :
-> Ses annonces le sont également et ne sont donc plus visibles sur les fiches produits concernées
-> Les articles mémorisés portant sur les fiches produit, ces annonces supprimées ne sont pas accessibles par ce biais

Alors que sur l'auto :
-> Les annonces passent bien en visibilité -2
-> Elles ne sont plus référencées par Fast et donc non accessibles dans la nav
-> Elles restent cependant accessibles via les articles mémorisés et les utilisateurs ayant mémorisé cette "annonce" peuvent toujours acccéder aux coordonnées du vendeur

...

Il semble donc y avoir différentes solutions :
-> Lors de l'affichage d'une annonce ou d'une fiche produit complément, vérifier systématiquement que celle-ci a bien une visibilité >=0
-> Lors du passage d'une annonce en visibilité <0, supprimer toutes entrées de type "WISH" référençant le product_id concerné


Je pense que cela concerne plutôt les équipe de Martin et/ou Edouard.
Commentaire de Nicolas Chauveau [ 11/déc./07 15:19 ]
A prioriser en CoPôle
Commentaire de Benoît Bourdon [ 21/avr./08 14:19 ]
évolution :
 -> Lors de l'affichage d'une annonce ou d'une fiche produit complément, vérifier systématiquement que celle-ci a bien une visibilité >=0





[APP-19994] [Evenements] BO modifie la qualité de l'annonce, mais affiché Vendeur Création: 25/mars/08 19:06  Mise à jour: 24/sept./08 11:29  Résolue: 18/sept./08 08:42

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 19.2.1
Version(s) corrigée(s): 30.0.0 (CAT-D)

Type: Bogue Priorité: Mineur
Rapporteur: Espérance Galouo-Lece Attribution: Dispatcher (Pôle CAT)
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File BO_modifie_qualité_mais_affiché_Vendeur.JPG    
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***
Classif1: BO
Classif2: événement annonce

 Description   
Logs :

2008-03-25 18:55:23,460 INFO [P-Processor8] O:Non_identifié - >>> GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293
2008-03-25 18:55:23,514 INFO [P-Processor8] O:Non_identifié - <<< [54 ms] GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293
2008-03-25 18:55:38,151 INFO [P-Processor7] - connection timeout reached
2008-03-25 18:55:41,773 INFO [P-Processor8] O:Non_identifié - >>> POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=20&comment=testInteg&cur
rencyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=39&y=10
2008-03-25 18:55:41,818 INFO [P-Processor8] O:Non_identifié - (Status : 302) Redirecting to : /advert_back?action=advertbackview&advertid=62900293
2008-03-25 18:55:41,818 INFO [P-Processor8] O:Non_identifié - <<< [44 ms] POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=20&comment=testI
nteg&currencyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=39&y=10
2008-03-25 18:55:41,836 INFO [P-Processor7] O:Non_identifié - >>> GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293
2008-03-25 18:55:41,869 INFO [P-Processor7] O:Non_identifié - <<< [33 ms] GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293
2008-03-25 19:00:34,215 INFO [P-Processor7] O:Non_identifié - >>> POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=40&comment=testInteg&cur
rencyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=26&y=12
2008-03-25 19:00:34,271 INFO [P-Processor7] O:Non_identifié - (Status : 302) Redirecting to : /advert_back?action=advertbackview&advertid=62900293
2008-03-25 19:00:34,271 INFO [P-Processor7] O:Non_identifié - <<< [56 ms] POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=40&comment=testI
nteg&currencyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=26&y=12
2008-03-25 19:00:34,299 INFO [P-Processor8] O:Non_identifié - >>> GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293
2008-03-25 19:00:34,335 INFO [P-Processor8] O:Non_identifié - <<< [36 ms] GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293
2008-03-25 19:00:42,846 INFO [P-Processor7] O:Non_identifié - >>> POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=10&comment=testInteg&cur
rencyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=23&y=10
2008-03-25 19:00:42,871 INFO [P-Processor7] O:Non_identifié - (Status : 302) Redirecting to : /advert_back?action=advertbackview&advertid=62900293
2008-03-25 19:00:42,872 INFO [P-Processor7] O:Non_identifié - <<< [26 ms] POST http://www.es.integ/advert_back!action=advertback...&advertid=62900293&advqualitycode=10&comment=testI
nteg&currencyid=978&quantity=900&saleprice=5000.0&serialnumber=3168416841...&x=23&y=10
2008-03-25 19:00:42,898 INFO [P-Processor8] O:Non_identifié - >>> GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293
2008-03-25 19:00:42,956 INFO [P-Processor8] O:Non_identifié - <<< [58 ms] GET http://www.es.integ/advert_back?action=advertbackview&advertid=62900293


 Commentaires   
Commentaire de Nicolas Chauveau [ 26/mars/08 14:44 ]
C'est une évolution.
Cela nécessite un nouvel événement (=> impact BI).
Est-ce nécessaire ?
Commentaire de Quentin de Chivré [ 26/mars/08 15:09 ]
On pourrait juste changer le libellé de l'venement, ca suffirait largement
Commentaire de Geneviève Beaujard [ 18/sept./08 08:42 ]
Ajout de '(BO)' dans la description.

Checking in advert/AdvertInput.java;
/home/cvs/dev/source/src/com/babelstore/advert/AdvertInput.java,v <-- AdvertInput.java
new revision: 1.98.136.1; previous revision: 1.98
done
Checking in advert/back/AdvertBackUpdateAction.java;
/home/cvs/dev/source/src/com/babelstore/advert/back/AdvertBackUpdateAction.java,v <-- AdvertBackUpdateAction.java
new revision: 1.16.354.1; previous revision: 1.16
done
Checking in stock/entity/Advert.java;
/home/cvs/dev/source/src/com/babelstore/stock/entity/Advert.java,v <-- Advert.java
new revision: 1.65.12.2; previous revision: 1.65.12.1
done




NpF Vidéo FR (CAT-104)

[CAT-105] NpF Video FR - Calcul des taux de remplissage des attributs Création: 15/oct./07 15:24  Mise à jour: 08/nov./07 11:54  Résolue: 05/nov./07 15:54

Etat: Résolu
Projet: Paramétrage - Non Import
Composants: Outils internes / Rapport
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Marion Anfreville Attribution: Julien Sananikone
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel npf-video_bluray.xls     Microsoft Excel npf-video_dvd_autres_zones.xls     Microsoft Excel npf-video_dvdz1.xls     Microsoft Excel npf-video_dvdz2.xls     Microsoft Excel npf-video_hddvd.xls     Microsoft Excel npf-video_vhs.xls    
Pays:
FRA - France

 Description   
Afin de permettre aux commerciaux de définir les filtres pour l'univers VIDEO, il faut calculer le taux de remplissage (sur la base de reporting) des types / mediums appartenant à cet univers. => voir doc pour calcul taux de remplissage http://ruinart.lan:4080/pricewiki/Wiki.jsp?page=TauxUtilisationAttribut

 Commentaires   
Commentaire de Julien Sananikone [ 22/oct./07 10:47 ]
je vois pas la pièce jointe
Commentaire de Marion Anfreville [ 22/oct./07 17:33 ]
pas de pj, juste une doc...
Commentaire de Julien Sananikone [ 22/oct./07 17:42 ]
type video : 244285 produits

type Vidéo en pré-commande : 966 produits
Commentaire de Julien Sananikone [ 26/oct./07 16:16 ]
voila pour les vhs
Commentaire de Julien Sananikone [ 30/oct./07 16:22 ]
le comptage est biaisé car on est en train de faire l'import de notre nouveau référentiel DVDZ2/Bluray/HDDvd : mais les pourcentages ne peuvent que s'améliorer
Commentaire de Julien Sananikone [ 05/nov./07 15:53 ]
les comptages faits en integ après l'intégration de la base complète dvd-fr et de l'enrichissement des produits non dvd-fr confirment bien les premiers comptages

l'enrichissement sur la prod n'a pas encore été fait mais on devrait retomber sur les mêmes bases que l'integ puisqu'on opère le même enrichissement.
Commentaire de Julien Sananikone [ 05/nov./07 15:54 ]
les comptages donnent lieu à l'établissement des filtres CAT-106




[APP-20908] [COSAV] Conditionner les macros "remboursement" selon si panier 1euro.com ou non Création: 19/juin/08 17:44  Mise à jour: 07/janv./09 15:46  Résolue: 05/déc./08 15:10

Etat: Fermé
Projet: Application PriceMinister
Composants: Back-Office
Affecte la/les version(s): 31.0.0 (TX-C)
Version(s) corrigée(s): 38.0.0 (TX-D Bis)

Type: Amélioration Priorité: Critique
Rapporteur: Cedric Favero Attribution: Geneviève Beaujard
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg     JPEG File screenshot-2.jpg    
Liens des demandes:
Duplicate
doublon de APP-22633 Fonctionnement macro Remboursement 1e... Fermé
Similaire
similaire à APP-21741 Modification macro "Garantie rétracta... Fermé
Pays:
FRA - France
Projets PM: *** RESERVE ***
Classif1: BO
Classif2: macros

 Description   
Lorsque la transaction a été effectuée avec un paiement 1euro.com et qu'une réclamation amène un remboursement , nous ne devons jamais effectuer de remboursement porte-monnaie mais suivre une procédure particulière pour transmettre les demandes de remboursement à COFIDIS/1EURO.

Il faudrait donc sur la fiche article que les macros "remboursement PMV" n'apparaissent pas lorsqu'il s'agit d'un panier 1euro.com et idéalement qu'à la place apparaissent une macro "remboursement 1euro.com" (qui ne ferait qu'envoyer le mail correspondant,le reste de la procédure étant manuelle).

Dans le cas où il ne serait pas possible de conditionner l'apparation de telle ou telle macro en fonction du mode paiement utilisé, il nous faudrait au moins une alerte (popup) lorsqu'on tente de faire un remboursement PMV alors que le panier est 1euro.com.

 Commentaires   
Commentaire de Emeric Teil [ 13/oct./08 17:44 ]
Traîté en TX-C ?
Commentaire de Cedric Favero [ 13/oct./08 17:49 ]
Oui mais pas correctement :

- ne doit apparaitre QUE si panier payé par 1euro
- doit envoyer un mail et ne le fait pas.

Je refais un JIRA ou on garde celui-ci?
Commentaire de Cedric Favero [ 20/oct./08 15:31 ]
Désolé pour le doublon , j'avais oublié ce JIRA.
Ma demande est toutefois plus claire dans le JIRA APP-22633
Commentaire de Cedric Favero [ 03/déc./08 10:02 ]
2 captures pour illuster le pb
Commentaire de Cedric Favero [ 03/déc./08 15:41 ]
Je n'ai meme pas les droits pour passer mon JIRA en critique ( c'est une conspiration)
Commentaire de Geneviève Beaujard [ 05/déc./08 15:10 ]
bzr ci source/src/com/babelstore/purchase/back/ItemView.jsp
Committing to: bzr://perrier/dev/pole/tx/
modified source/src/com/babelstore/purchase/back/ItemView.jsp
Committed revision 24741.

Cedric tu peux tester le résultat sur mon serveur:
item avec 1euro: http://bo.pm.boulard:2080/purchase_back?action=itemview&itemid=76245851
item sans: http://bo.pm.boulard:2080/purchase_back?action=itemview&itemid=78410228
Commentaire de Cedric Favero [ 05/déc./08 18:03 ]
Je ne saurais exprimer suffisamment la reconnaissance du SAV (des petits trucs semblant betes peuvent parfois etre tres penibles)

Par ailleurs j'insiste à nouveau sur la lourdeur que peuvent avoir parfois les process pour traiter des demandes finalement pas si complexes..

Il faut escalader des montagnes pour que puissent etre etudiées nos demandes!

Et je ne dis pas çà d'un aspect négatif mais plutot pour relever ce qu'il y a à améliorer.

Merci à tous et specialement à Genevieve :-)
Commentaire de Christophe Garcia [ 07/janv./09 15:12 ]
Cédric, que faites-vous quand le paiement s'est fait en partie via PMV et en partie via 1euro ?
Commentaire de Claire Durand [ 07/janv./09 15:17 ]

pour la partie payée par pmv, on recrédite le pmv avec la cause "remboursement 1¿"

la partie payée via 1¿ est remboursée par le biais de sips par moi-même

claire
Commentaire de Christophe Garcia [ 07/janv./09 15:46 ]
OK Merci




[APP-19035] Affichage chiffres tableaux de bord - Chiffres anormalement bas sur les catégories Mobilier, Décoration, Mode, Matériel de Sport Création: 19/déc./07 10:06  Mise à jour: 14/janv./08 12:42  Résolue: 02/janv./08 18:22

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 18.1.0
Version(s) corrigée(s): 18.1.3

Type: Bogue Priorité: Critique
Rapporteur: Stéphanie Vignali Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à APP-19034 Etude de l'alerte de Monitoring sur l... Fermé
Pays:
FRA - France
Site: Prod
Projets PM archivés: Maintenance 18.x.x

 Description   
En regardant les chiffres ce matin on a eu la très mauvbaise surprise de voir qu'ils étaient anormalement bas sur certaines catégories comme le mobilier, la déco, la mode sans parler du Matériel de Sport où il n'y a eu aucune vente ce qui n'est jamais arrivé depuis l'ouverture du rayon.

Pour exemples :
CA Mode : 2667 ¿ le 17/12 et 137 ¿ le 18/12
CA Mobilier : 3015 ¿ le 17/12 ¿ et 132 ¿ le 18/12
CA Matériel de Sport : 3375 ¿ le 17/12 et 0 ¿ le 18/12
CA Chaussures : 2183 ¿ le 17/12 et 192 ¿ le 18/12

C'est spécifique à nos catégories car les chiffres de scatgéories culturelles et high tech n'ont pas l'air impacté par cette énorme différence de chiffre d'affaire.



 Commentaires   
Commentaire de Emmanuelle Lachamp [ 19/déc./07 10:23 ]
Precision : les paniers ont l'air de disparaitre à vers 2 heures du mat
les categories concernees sont :

vetement
mobilier
decoration
materiel de sport
chaussures
vin
gastronomie
Accessoires cycle et cyclomoteur
Accessoires animalerie
Cosmétiques
2 Roues
linge de maison
loisirs creatif
plante
sac et bagagerie
Commentaire de Patrice Boulanger [ 19/déc./07 10:32 ]
Pouvez-vous m'indiquer ou et quand les informations de ce type sont calculées (en temps réel, par un batch, ça utilise FAST et/ou Oracle ?). De plus, on a eu des alertes cette nuit à 00h30 sur presque tous les serveurs, est-ce que ça pourrait avoir un rapport ? Le retard du connecteur Fast pourrait-il avoir un impact sur ces informations ?

Merci.
Commentaire de Emmanuelle Lachamp [ 19/déc./07 10:50 ]
C'est à nous que tu demandes ca ??
parce que là je crois que on n'en sait fichtre rien, nous ne sommes que de simples commerciaux
Commentaire de Stéphanie Vignali [ 20/déc./07 09:28 ]
Est ce quelqu'un peut regarder ec qui se passe car le problème persiste aujourd'hui.

C'est bloquant pour une équipe commerciale de ne pas avoir le CA de ses catégories.
Commentaire de Patrick Pereira [ 20/déc./07 18:49 ]
Si je regarde en base :

----depuis ce matin (20/12)

Nombre d'article de type vêtement mis en panier : 1

select count(*)
from item
where prd_type_code = 1480
and creation_date > to_date('19/12/2007','DD/MM/YYYY')
and creation_date < to_date('21/12/2007','DD/MM/YYYY');

  COUNT(*)
----------
         1

Nombre darticle de type vêtement en panier authorisé : 1

SELECT COUNT(distinct item_id) AS authorized_count
FROM purchase, item
WHERE item.purchase_id = purchase.purchase_id
AND purchase.authorization_date > to_date('19/12/2007','DD/MM/YYYY')
AND purchase.authorization_date < to_date('21/12/2007','DD/MM/YYYY')
AND item.itm_status_code <> 50
AND prd_type_code = 1480;

AUTHORIZED_COUNT
----------------
               1


----journée du 19

Nombre d'article de type vêtement mis en panier : 47
Nombre darticle de type vêtement en panier authorisé : 7

----journée du 18

Nombre d'article de type vêtement mis en panier : 1299
Nombre darticle de type vêtement en panier authorisé : 257


----journée du 17

Nombre d'article de type vêtement mis en panier : 2615
Nombre darticle de type vêtement en panier authorisé : 577


----journée du 16

Nombre d'article de type vêtement mis en panier : 2544
Nombre darticle de type vêtement en panier authorisé : 547


Il y a en effet une très forte baisse à partir du 19 mais qui ne correspond pas aux chiffres du tableau de bord.
Je vais vérifier la méthode de calcul.
Commentaire de Patrick Pereira [ 21/déc./07 11:43 ]
Le problème vient d'un changement de comportement de l'application qui depuis la V18_1 (le 18/12 à 5h00) stocke le prd_type_code du produit complément à la place du prd_type_code du produit de base.

Dans le vue agrégée (itm_period_summary) on a du coup :

Le 17/12 :

AUTHORIZED_COUNT AUTHORIZED_COST_PRICE_SUM PRD_TYPE_CODE
---------------- ------------------------- -------------
             252 6267.66 1480

Le 18/12:

AUTHORIZED_COUNT AUTHORIZED_COST_PRICE_SUM PRD_TYPE_CODE
---------------- ------------------------- -------------
               6 173.5 1480
             264 5719.19 1481

Le 19/12:

AUTHORIZED_COUNT AUTHORIZED_COST_PRICE_SUM PRD_TYPE_CODE
---------------- ------------------------- -------------
             180 3695.21 1481

Dans la table item on voit que les item prennent le prd_type_code du produit complément :
--------------------------


Pour la journée du 16 :

select count(*), prd_type_code
from item
where prd_type_code in( 1480,1481)
and creation_date > to_date('15/12/2007','DD/MM/YYYY')
and creation_date < to_date('17/12/2007','DD/MM/YYYY')
group by prd_type_code;

  COUNT(*) PRD_TYPE_CODE
---------- -------------
      2544 1480


Le 17 :

  COUNT(*) PRD_TYPE_CODE
---------- -------------
      2615 1480

Le 18 :

  COUNT(*) PRD_TYPE_CODE
---------- -------------
      1299 1480
      1158 1481

Le 19 :

  COUNT(*) PRD_TYPE_CODE
---------- -------------
        47 1480
      2245 1481

Le 20 :

  COUNT(*) PRD_TYPE_CODE
---------- -------------
         1 1480
      1834 1481


Alors que dans la table advert on a toujours le prd_type_code du produit de base.
Ex pour le 20 :

select count(*), prd_type_code
from advert
where advert_id in (
 select advert_id
from item
where prd_type_code = 1481
and creation_date > to_date('19/12/2007','DD/MM/YYYY')
and creation_date < to_date('21/12/2007','DD/MM/YYYY')
)
group by prd_type_code;


  COUNT(*) PRD_TYPE_CODE
---------- -------------
      1535 1480


=> dans le tableau de bord il faut tenir compte des produits compléments
ou
=> ne mettre que les prd_type_code des produits de bases dans le item.
Commentaire de Christophe Garcia [ 21/déc./07 11:45 ]
Modifier affichage BO en agrégeant PRD et PRD_CPLT
ou
Revenir à un stockage du PRD et pas du PRD_CPLT
Commentaire de Arnaud Forgues [ 26/déc./07 10:45 ]
La correction est mise en place au niveau applicatif : plus qu'à attendre le déploiement de la V18.1.3 pour que le problème soit rétabli.

En ce qui concerne la correction des données érronées depuis la V18.1 (mardi 18 décembre), 2 scripts sont prêts dans le répertoire V:\Database\V18.1.3\integ. Par contre on préferera attendre le retour de Patrick (le 2 janvier prochain) pour passer ces scripts en PROD.

-------------------------

APP-19035 [V18.1.3] affect good type from base product to item in all cases
CVS: ----------------------------------------------------------------------
CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS: Tag: BRANCH_V18
CVS: src/com/babelstore/purchase/business/ItemBusinessBean.java
CVS: ----------------------------------------------------------------------
Commentaire de Arnaud Forgues [ 28/déc./07 11:13 ]
La V18.1.3 a été mis en PROD ce matin !

Les chiffres devraient donc revenir partiellement demain (tout sauf ce qui a été vendu avant 5h du matin) et totalement après demain :D
Pour les chiffres depuis le 18/12 jusqu'à aujourd'hui, Patrick et moi passeront des scripts la semaine prochaine afin de les récupérer, cependant il ne s'agit que de données informatives et il vaut mieux se baser sur du reporting BI pour avoir de vrais chiffres métier quoi qu'il arrive ;-)

Voilou,
Arnaud
Commentaire de Arnaud Forgues [ 28/déc./07 11:14 ]
je le réouvre juste pour penser aux scripts !
Commentaire de Christophe Garcia [ 02/janv./08 10:24 ]
Ils en sont où ces scripts ?
Commentaire de Stéphanie Vignali [ 02/janv./08 10:31 ]
On les attends avec impatience !
Commentaire de Patrick Pereira [ 02/janv./08 18:22 ]
Les scripts sont passés.
Vous pouvez retrouver les véritables chiffres sur les tableaux de bord.




[APP-20915] Tracking Question et Souhait Création: 20/juin/08 10:02  Mise à jour: 07/sept./09 12:17  Résolue: 07/sept./09 11:56

Etat: Fermé
Projet: Application PriceMinister
Composants: Tracking
Affecte la/les version(s): 23.0.3
Version(s) corrigée(s): 52.0.0 (CTN-M)

Type: Bogue Priorité: Majeur
Rapporteur: Charles Decaux Attribution: Renaud Dierickx
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne
Site: Prod
Projets PM: *** CHASSE ***
Classif1: PROMO
Classif2: chasse

 Description   
Hello,

je pense que le tracking question et le tracking souhait ne sont pas correctement implémentés en Espagne.: aucune remontée sur ces trackings en terme de visites et en terme d'achats. Par ailleurs, dans le BO on ne retrouve aucune trace de ces trackings.

Peut-on faire une passe dessus pour voir comment le mettre en place correctement ?

Merci

 Commentaires   
Commentaire de Swan Desportes [ 24/juin/08 09:54 ]
A faire en JIRA hebdo
Commentaire de Clement Balay [ 22/juil./08 14:57 ]
Est-ce que l'on pourrait avoir plus de précisions sur les liens mis en cause.
Par exemple une capture d'écran du lien en question ou le nom du lien et la page sur laquelle il est.

merci
Commentaire de Fabrice Feugas [ 20/janv./09 13:42 ]
Pas de nouvelles de ce JIRA depuis juillet. Peut-on considérer que c'est ok?
Commentaire de Charles Decaux [ 20/janv./09 15:31 ]
Hello !

Non malheureusement ce n'est pas corrigé.
Que ce soit dans Xiti ou dans BI, je n'ai aucune donnée (pas de visite, pas de panier) liée aux trackings QUESTION ou SOUHAIT.

Les liens mis en cause sont :
- le mailing souhait qui part quand un souhait se réalise
- concernant la question, je ne connais pas la procédure d'allocation du tracking. Est-ce qu'il se retrouve avec un tracking question dès lors qu'il en pose une ? Ou bien existe-t-il un lien spécifique qui doit être tracké ? Je pense qu'il faudrait jeter un coup d'oeil aux spécifications et à ce qu'on constate sur la France pour répliquer le même schéma sur l'Espagne.

Merci
Commentaire de Renaud Dierickx [ 04/sept./09 17:10 ]
C'est parce que les tracking n'existent pas !

>>>> Pour les souhaits, le code de tracking est : 30

Existe sur :
>> FR : http://bo.priceminister.com/tracking_back?action=trackingsearch&name=&usr_tracking_id=30&start_date=&end_date=&number_rows=100&x=51&y=15
>> UK : http://bo.priceminister.co.uk/tracking_back?action=trackingsearch&name=&usr_tracking_id=30&start_date=&end_date=&number_rows=100&x=12&y=5

N'existe pas sur
>> ES : http://bo.priceminister.es/tracking_back?action=trackingsearch&name=&usr_tracking_id=30&start_date=&end_date=&number_rows=100&x=15&y=11


>>>> Pour les questions, le code de tracking est : 40

Existe sur :
>> FR : http://bo.priceminister.com/tracking_back?action=trackingsearch&name=&usr_tracking_id=40&start_date=&end_date=&number_rows=100&x=51&y=15
>> UK : http://bo.priceminister.co.uk/tracking_back?action=trackingsearch&name=&usr_tracking_id=40&start_date=&end_date=&number_rows=100&x=12&y=5

N'existe pas sur
>> ES : http://bo.priceminister.es/tracking_back?action=trackingsearch&name=&usr_tracking_id=40&start_date=&end_date=&number_rows=100&x=15&y=11


====================> JE VAIS LES CREER PAR SCRIPT !
Commentaire de Renaud Dierickx [ 04/sept./09 17:58 ]
[CAJ2009Q3CTN]
Commentaire de M'hand Hadjoudj [ 07/sept./09 11:52 ]
Ils sont où les scripts ? (ne pas répondre DTC)
Commentaire de Renaud Dierickx [ 07/sept./09 11:56 ]
Dans le répertoire où il y a les scripts de la V52_0_0...
V:\Database\V52_0_0\integ\01_PREPARE\ONLINE\done
Commentaire de M'hand Hadjoudj [ 07/sept./09 12:08 ]
OK merci.
Pour info, les noms des scripts doivent comporter le numéro du JIRA.




[BIN-453] [Jeu permanent vendeur] : Rapport ventilation nb de vendeur par nb de vente Création: 02/juin/08 16:01  Mise à jour: 17/sept./08 12:30  Résolue: 17/juil./08 11:21

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Charlotte Fachan Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Individual seller distribution by item count.xls    
Pays:
FRA - France

 Description   
Bonjour,

dans le cadre de la mise en place de notre jeu concours permanent vendeur, nous aurions besoin de définir des catégories de vendeur (gros, moyen, petit).
Serait -il possible d'avoir un rapport sur le modele du rapport Buyers distribution by purchase count mais orienté vente.

A votre dispo pour s'en parler.

Merci

Charlotte

 Commentaires   
Commentaire de Florian Ambrosi [ 09/juin/08 17:31 ]
Le rapport "Individual seller distribution by item count" est passé en prod en France et en Espagne dans le dossier "Item".

Florian.
Commentaire de Charlotte Fachan [ 16/juin/08 16:55 ]
Merci pour ce rapport.

Petite précision : cela concerne que les vendeurs part ?
on parle bien en nombre de vente ou en nombre d'annonce ?

Merci de ton retour.

Bonne journée

Charlotte
Commentaire de Florian Ambrosi [ 16/juin/08 17:03 ]
Charlotte,

Le rapport concerne les vendeurs particuliers et il s'agit du nombre de vente.

Florian.
Commentaire de Charlotte Fachan [ 16/juin/08 17:08 ]
Super !

merci Florian
Commentaire de Charlotte Fachan [ 30/juin/08 19:49 ]
Bonjour Romain,

comme convenu ensemble, pourrais tu me transmettre ce rapport avec tout l'historique vente / vendeurs depuis le début de PriceMinister.

Merci beaucoup

Charlotte
Commentaire de Charlotte Fachan [ 16/juil./08 17:02 ]
Romain,

comme convenu pourrais tu me transmettre ce rapport. J'en ai vraiment besoin afin de définir les différentes catégories de vendeur et les intégrer dans le réglement final (qui n'attend plus que cette donnée pour être intégré ds infoglue)

Merci

Charlotte
Commentaire de Romain Czornomaz [ 16/juil./08 17:46 ]
Julien,

Avant de démarrer les dev sur le rapport de tirage au sort, il faut fournir les données de segmentation.
Peux tu t'en occuper?
Romain
Commentaire de Julien Girardet [ 17/juil./08 11:19 ]
Resultat du rapport "Individual seller distribution by item count " (ITEM) pour tout l'historique de PriceMinister
Commentaire de Julien Girardet [ 17/juil./08 11:21 ]
Bonjour Charlotte,

tu trouveras en piece jointe du JIRA le fichier excel du resultat du rapport "Individual seller distribution by item count " pour tout l'historique de Price.

Julien
Commentaire de Charlotte Fachan [ 18/juil./08 18:04 ]
Merci julien,

je regarde asap et vous tiens informé

Charlotte
Commentaire de Agathe Remy [ 17/sept./08 12:30 ]
Suite au point hebdo BI, il semble que le tirage au sort se soit bien passé.
Je clôture donc ce JIRA.

Agathe




[BIN-312] [TFV] : Rapport géolocalisation des vendeurs recrutés Création: 02/avr./07 14:59  Mise à jour: 14/sept./07 18:03  Résolue: 04/mai/07 15:10

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Thomas Beylot Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello,

Jira dont j'ai déjà parlé avec Romain. L'idée est de construire un rapport qui me donne le nombre de nouveaux vendeurs recrutés sur une période en fonction des départements.

En effet, suite à l'OP la poste nous aimerions savoir si celle-ci a poussé le recrutement de vendeurs dans les départements concernés.

Ainsi, j'ai construit un rapport tout seul comme un grand que j'ai donc soumis à Romain car les résultats me semblaient bizarres (par exemple sur la semaine du 19 au 25 mars il me sort 1 211 nouveaux vendeurs alors que par exemple le mois dernier on en avait recruté 12 906...).
Le rapport est dispo dans mes favoris sous un nom compréhensible (géoloc etc).

Pouvez-vous regardé ça et me dire ce qu'il en est ?

A titre indicatif j'ai le nb de nouveaux vendeurs recrutés par mois (et pas par période, malheureusement):
- 16 962 en janvier
- 12 906 en février

datas qui proviennent des rapports titan.


merci !!

thomas.

 Commentaires   
Commentaire de Thomas Beylot [ 04/avr./07 11:35 ]
hello,

suite à un petit travail sur Bo avec Romain, on se rend compte que cette demande mériterait de passer en "mode projet"... en effet on obtient des chiffres qui ne sont pas en adéquation avec ceux de François et donc il faut qu'on mène l'enquete.

A prioriser dans la liste des demandes...


merci !

thomas.
Commentaire de Romain Czornomaz [ 27/avr./07 14:05 ]
Salut Thomas,

Le rapport sur la géolocalisation des nouveux vendeurs est en prod sur la plateforme BI dans le repertoire suivant:
France/Seller/Priceminister - Sellers geolocalization

Peux tu le valider et fermer le JIRA ensuite :)

Merci d'avance,

Romain


Commentaire de Romain Czornomaz [ 04/mai/07 15:10 ]
Thomas,

Je passe la demande en resolu. si tu as un problème lié au rapport, n'hésites pas à la réouvrir.

:)

Romain
Commentaire de Thomas Beylot [ 22/mai/07 18:54 ]
yo

juste je me permets de réouvrir le pti jira pour savoir si tu avais reçu mon magnifique mail pour vérifier 2/3 trucs sur le rapport...




[EXP-4149] installation modules PERL sur Pommery : DBI (avec driver Oracle) + AppConfig Création: 31/déc./07 10:52  Mise à jour: 25/janv./08 11:42  Résolue: 25/janv./08 11:42

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Samir Beghdadi Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
salut,

pourrais tu m'installer les modules PERL sur Pommery : DBI (avec driver Oracle) + AppConfig

merci d'avance

julien GIRARDET
julien.girardet@priceminister.com

 Commentaires   
Commentaire de Jérémie Bennejean [ 31/déc./07 11:45 ]
Le module DBI est installé sur pommery. test ok
idem pour AppConfig
Commentaire de Jérémie Bennejean [ 31/déc./07 11:46 ]
Merci de m'indiquer si tout est fonctionnel de votre coté.
Commentaire de Samir Beghdadi [ 31/déc./07 14:02 ]
merci pour DBI + AppConfig
peux tu également installer le driver DBD::Oracle ainsi que le module MIME::Lite

merci d'avance

Julien.
Commentaire de Jérémie Bennejean [ 31/déc./07 16:22 ]
Installé.
Pouvez-vous vérifier de votre coté?
Merci
Commentaire de Jérémie Bennejean [ 04/janv./08 10:20 ]
N'ayant pas de réponses je résouds.
Commentaire de Julien Girardet [ 04/janv./08 14:39 ]
Le module MIME::Lite est bien installé sur Pommery, cependant pour fonctionner correctement j'ai besoin du module Email::Date::Format
Donc peux tu m'installer le module Email::Date::Format sur Pommery ?

Désolé des demandes successives d'installation de module, mais je découvre au fur à mesure les modules dont j'ai besoin.

merci
Commentaire de Jérémie Bennejean [ 04/janv./08 15:51 ]
C'est installé
Commentaire de Julien Girardet [ 04/janv./08 16:16 ]
voici le message d'erreur que j'obtiens :

Use of uninitialized value in substitution (s///) at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 511.
Use of uninitialized value in scalar assignment at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 513.
Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 514.

apparement des valeurs du module MIME::Lite ne sont pas initialisées...
Commentaire de Jérémie Bennejean [ 04/janv./08 16:20 ]
J'ai réinstallé avec une autre méthode.
L'installation est ok.
Commentaire de Julien Girardet [ 04/janv./08 16:58 ]
j'ai toujours le meme message d'erreur :

Use of uninitialized value in substitution (s///) at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 511.
Use of uninitialized value in scalar assignment at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 513.
Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/site_perl/5.8.5/MIME/Lite.pm line 514.
Commentaire de Jérémie Bennejean [ 07/janv./08 11:06 ]
Salut,

Le script suivant fonctionne:

#!/usr/bin/perl -w
# Created test_email.pl the 13:29:09 (31/10/2006) on hercule
#
#
# Application Priceminister
# email: exploitation@priceminister.com
# Documentation:
# http://wikiexploit/
use lib '/data/mrtg/perl';
use strict;
use MIME::Lite;

   my $subject = 'Essai on Hercule';

        my $mailmsg = "Essai de mail\n";

        my $msg = MIME::Lite->new(
                From => 'pmas@priceminister.com',
                To => 'hostmaster@priceminister.com',
                Subject => 'report on Hercule',
                Type => 'TEXT',
                Data => $mailmsg,
        );

# $msg->attach(
 # Type => 'x-gzip',
  # Path => "ess.txt",
   # );

# ftpCompute is still on beta test so, we mail
        $msg->send;

#$(uencode ess.txt | sendmail -t "eric.vannier@priceminister.com <mailto:eric.vannier@priceminister.com>")

Je pense que MIME est bien installé, cela doit venir de ton script.

Merci
Commentaire de Julien Girardet [ 07/janv./08 11:41 ]
salut,
J'ai testé également de mon coté, le module MIME fonctionne.
l'erreur provenait bien de mon script, il manquait en début de script : use lib '/data/mrtg/perl';

Merci.
Commentaire de Jérémie Bennejean [ 07/janv./08 12:14 ]
Je ferme le jira alors.

Commentaire de Julien Girardet [ 10/janv./08 17:41 ]
Salut,

Dans le cadre d'une future mise en PROD du projet SANITY CHECK BI
Je souhaiterais que les modules PERL installés sur Pommery le soit également sur LATONE
Peux tu faire le necessaire aupres de JET.

Pour rappel, les modules PERL necessaires :
DBI
DBD::Oracle
AppConfig
MIME::Lite
Email::Date::Format

Merci
Commentaire de Patrice Boulanger [ 10/janv./08 18:00 ]
Vous avez les accès nécessaires auprès de Jet pour créer les MAI (voir avec Agathe si nécessaire), il n'y a pas nécessité de passer par nous pour cela, ça fera des interlocuteurs supplémentaires pour rien.

Patrice.
Commentaire de Julien Girardet [ 11/janv./08 12:15 ]
A l'intention d'Agathe :

Apres avoir verifié les modules PERL installés sur LATONE, voici les modules manquant qui feront l'objet d'une demande d'installation aupres de JET :

- Module MIME::Lite
- Module AppConfig
- Module Email::Date::format

les modules DBI et DBD::ORACLE sont deja installés sur LATONE
Commentaire de Agathe Remy [ 15/janv./08 18:37 ]
15/01/2008 15:09 JMH Ajout des modules suivants en prérequis de MIME::lite :
Mail::Address
MIME::Types
File::Basename
MIME::Base64
MIME::QuotedPrint

15/01/2008 15:51 JMH Modules effectivement installés ::
TimeDate-1.16

Pod-Escapes-1.04
Pod-Simple-3.05
Test-Simple-0.74
Test-Pod-1.26
MailTools-2.02

MIME-Base64-3.07 ( gcc )
MIME-Types-1.23
Email-Date-Format-1.002

MIME-Lite-3.021
AppConfig-1.66

15/01/2008 15:53 JMH Cela correspond-t-il à la demande ?
Commentaire de Julien Girardet [ 16/janv./08 10:55 ]
Les modules sont bien installés sur Latone et fonctionnent

Merci.




[BIN-415] Opt-in partenaires Espagne Création: 18/févr./08 14:55  Mise à jour: 18/févr./08 15:09  Résolue: 18/févr./08 15:09

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Charles Decaux Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne

 Description   
La fonctionnalité opt-in partenaires est désormais active sur l'Espagne.

Avant que cette fonctionnalité ne soit active, nous avons inséré de nombreux contacts grâce aux différentes opérations que nous avons menées.

Certains de ces contacts étaient opt-in partenaires. Il faudrait donc mettre à jour l'intégration de ces contacts en prenant en compte leur statut "opt-in partenaires".

Merci



 Commentaires   
Commentaire de Agathe Remy [ 18/févr./08 15:09 ]
Charles,

Le BI ne modifie jamais les données du site.
Il faut que tu vois cela avec l'équipe d'exploitation : Patrick ou Eric qui s'occupe de l'intégration des contacts des jeux concours?!

Agathe




[APP-18727] [CoSAV] Filtrer les paniers en observation Création: 27/nov./07 16:46  Mise à jour: 27/nov./09 12:14

Etat: Ré-ouvert
Projet: Application PriceMinister
Composants: Back-Office
Affecte la/les version(s): 17.2.1
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Mineur
Rapporteur: Sebastien Bruzzone Attribution: Dispatcher (Pôle TX)
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM: *** STANDBY ***
Classif1: PANIER
Classif FONC: CoSAV

 Description   
Bonjour,

Nous aimerions pouvoir trier les paniers en observation.

http://bo.priceminister.com/purchase_back?action=purchasesearch&fuzzy=false&numberrows=200&order=1&pchstatuscode=120

et

http://bo.priceminister.es/purchase_back?action=purchasesearch&fuzzy=false&numberrows=200&order=1&pchstatuscode=120


En effet nous sommes actuellement dans une période de forte croissance où nous devons traiter 600 paniers le lundi matin avec aucun tri possible.

A ce jour, les paniers en obs sont uniquement triés par ordre chonologique, nous aimerions pouvoir avoir des tris par type, cb (montant), 1¿ , PMV, cpn, date

Avoir des filtres permettrait à l'équipe de pouvoir traiter plus efficacement les paniers en se repartissant le travail sur des jours, les montants ou les types de panier.


 Commentaires   
Commentaire de Agathe Remy [ 27/nov./07 19:38 ]
Sébastien,

Ce n'est pas l'équipe BI qui s'occupe du BackOffice (http://bo.priceminister.com).
Nous ne gérons que le portail BI (http://bi.priceminister.com).
Je déplace donc ta demande dans le projet Application géré par l'équipe Etude&Dévéloppement.

Cordialement,
Agathe
Commentaire de Emeric Teil [ 07/févr./08 14:10 ]
A prendre en compte dans les demandes de type CoSAV.
Commentaire de Cedric Favero [ 03/févr./09 18:22 ]
Sebastien , peux tu faire un document regroupant tes demandes d'amélioration pour la page de paniers en observations:

- Options de tris nécessaires
- Données supplémentaires à faire figurer (ex: mode de paiement, mode d'expédition, etc..)
- Options d'affichage eventuellement (certaines données à faire ressortir?)


On le verra ensemble et on le joindra à ce JIRA.

Merci.
Commentaire de Emeric Teil [ 04/nov./09 18:04 ]
Passe dans notre backlog...
Commentaire de Christophe Garcia [ 05/nov./09 18:30 ]
MDPLVC
Commentaire de Christophe Garcia [ 27/nov./09 12:00 ]
Je réouvre en attendant que l'on trouve la bonne marche à suivre pour ces types de demandes.
A traiter en backlog ? A traiter dans JIRA ?
Comments ces projets reviennent-ils sur la table s'ils sont traités en backlog ? Création de nouveaux JIRA ?




[APP-20567] [UK] Mise en place de la page alpha Création: 20/mai/08 10:35  Mise à jour: 15/juil./08 15:44  Résolue: 04/juil./08 17:04

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 25.0.0 (CTN-D)
Version(s) corrigée(s): 25.0.0 (CTN-D)

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Swan Desportes Attribution: Rémi Virlouvet
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: Microsoft Word Brief page alpha.doc    
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-20988 Problème d'inscription adresse e-mail... Sub-bug Fermé Swan Desportes  
Pays:
GBR - Royaume Uni
Projets PM: *** RESERVE ***

 Description   
Mise en place de la page beta avec formulaire d'inscription (cf. inscription NL de la HP) : voir brief de CDE.

 Commentaires   
Commentaire de Charles Decaux [ 20/mai/08 16:46 ]
Voici le brief, pas validé par les chefs, mais à priori ils ne feront que des modifs de texte.

N'hésitez pas si vous avez besoin d'aide. Je n'ai pas donné d'orientation graphique, mais je pense que le mieux c'est de faire du PriceMinister.

Merci
Commentaire de Charles Decaux [ 21/mai/08 18:46 ]
Voici les commentaires des caïds sur ce brief :

- se laisser la possibilité de modifier la page afin de motiver l'inscription par un jeu concours...
- priviliégier graphiquement le formulaire d'inscription aux liens vers PM FR et PM ES

Sinon c'est good !

Merci
Commentaire de Clement Balay [ 22/mai/08 16:19 ]
Ça y est, j'ai mis en place le prototype de la page alpha qui est disponible à cette adresse: /info/alpha, Le contenu peut être modifié dans ce contenu:
/default/Article/Main Article/AlphaPage.

Pour modifier certains wordings spécifique UK, il faut modifier les labels en version UK ici: /default/Labels/_Mon Compte/NewsletterPopup/*
Commentaire de Clement Balay [ 22/mai/08 16:21 ]
Les labels spécifique à mettre dans les labels sont indiqués dans le brief qui en pièce jointe du jira
Commentaire de Clement Balay [ 22/mai/08 16:26 ]
mes publications:
CMS1 - default - ALPHA_PAGE
CMS1 - default - AlphaPage
Commentaire de Charles Decaux [ 02/juin/08 12:20 ]
Hello,

la pop up qui s'ouvre quand on clique sur le bouton GO est en français. Il faudrait la mettre en anglais avec le texte prévu dans le brief à cet effet.

Merci
Commentaire de Ariane Baldinger [ 02/juin/08 16:12 ]
page accessible ici : http://www.pm.bollinger:2680/info/alpha
Commentaire de Rémi Virlouvet [ 06/juin/08 11:45 ]
pop up traduite.
que reste t il exactement à faire?
Commentaire de Rémi Virlouvet [ 06/juin/08 11:51 ]
page désormais accessible ici : http://bouk.priceminister.jmh/info/alpha
Commentaire de Charles Decaux [ 09/juin/08 10:27 ]
Hello Rémi,

En fait dans le brief que j'ai livré, il y avait plusieurs spécifications concernant la popup de confirmation :

- si possible le faire par le biais d'une alerte javascript et non pas une popup
- il faudrait que l'inscription soit immédiate et non pas en deux temps .Dans la pop up, quand on met son mail, il faut reconfirmer qu'on veut s'inscrire. Cette étape n'est pas nécessaire. Une fois que l'internaute a renseigné son mail et cliqué sur "Go" alors c'est bon, il est inscrit, il faut juste mettre un message de confirmation. En revanche il faudrait vérifier avec les dévs que c'est possible.
- enfin la traduction de cette pop up avait déjà été livrée dans le brief. Evidemment cette traduction est valable seulement si on peut inscrire l'internaute immédiatement et ne pas attendre sa confirmation.

Merci et à ta dispo pour en parler.

Charles

Commentaire de Swan Desportes [ 09/juin/08 11:21 ]
Hello Charles

- pour le popup --> c'est du DEV. On garde le système actuel, sinon il faut faire un mini projet...
- pour l'inscription immédiate : mais remarque que ci dessus.
- il faut donc adapter le wording.

On a décidé de faire simple et efficace parce que l'on n'a pas les moyens de faire autrement avec les délais actuels. D'autre part, on tient absolument à ce que FR, ES et UK soient identiques. Donc ce dev dépasserait le simple cadre de UK (à discuter en CoMarket).

Merci et à ta dispo pour en parler.

Swan
Commentaire de Charles Decaux [ 10/juin/08 09:35 ]
ok merci Swan, je vais en parler avec Odile afin qu'elle fasse éventuellement la demande de simplification de l'inscription lors du prochain comarket.
Commentaire de Charles Decaux [ 12/juin/08 19:05 ]
Swan --> Big bug : quelque soit le mail que je mettre sur http://bouk.priceminister.jmh/info/alpha il me dit que je suis déjà inscrit.

C'est peut-être un souci de connexion à la base... Je ne sais pas
Commentaire de Charles Decaux [ 12/juin/08 19:10 ]
Rémi : peux-tu apporter les améliorations suivantes à la page :

- javascriptage des liens (c'est sûrement côté Clément)
- ajouter un texte à la fin de la page qui dit "Interested in PriceMinister ? Give us your opinion and help us out ! "
Le lien à mettre sur ce texte http://vovici.com/wsb.dll/s/e27fg34d48
Si tu penses qu'il faut reformuler cette phrase n'hésite pas.

Enfin, on va sûrement faire un jeu concours permanent pour les personnes qui s'inscrivent, il faudra peut être remplacer "please write down your email " par "please write down your email. If you are lucky, you might win £100 !".
Et du coup il faudra peut être ajouter un lien en bas de la page vers le règlement du jeu concours.

Merci


Commentaire de Charles Decaux [ 16/juin/08 19:07 ]
Patrice, Swan,

quand je clique sur une page qui ne devrait pas être accessible, j'arrive sur une page qui dit
"Status: 503 Server Full Content-type: text/html Cache-Control: private "

Serait-il possible de remédier à cela ? Il faudrait qu'on arrive sur la page alpha.

Merci

Commentaire de Charles Decaux [ 25/juin/08 19:36 ]
Rémi,

est-ce que toutes les modifications demandées sont bien prêtes ?
As-tu mis un lien vers le jeu concours ?

Merci de ton retour
Commentaire de Rémi Virlouvet [ 26/juin/08 17:28 ]
Swan, tout est ok sauf que quelque soit l'adresse renseignée, il indique que l'adresse existe déjà .

Par ailleurs, le logo affiché est celui de la france, il faudrait mettre un logo sans base line et avec code barre

merci et à ta dispo
Commentaire de Rémi Virlouvet [ 26/juin/08 17:43 ]
p.s. : le commentaire ci dessus est de Charles :)
Commentaire de Swan Desportes [ 27/juin/08 15:23 ]
Pour le wording, tu as la main : tout est dans IG.
Pour le fonctionnement de l'inscription, tu pourrais me faire un sous-jira. Merci.
Commentaire de Charles Decaux [ 27/juin/08 18:41 ]
Il faudrait remplacer
"It should be ready at the end of 2008." par "It will be opening soon" ou quelque chose du genre, sans préciser de date.
merci.
Commentaire de Rémi Virlouvet [ 30/juin/08 12:19 ]
Done.




mail de notification de deploiement reussi : je ne l'ai pas recu pour venus et pour rhome (EXP-3645)

[EXP-3681] Surveillance conf mail des serveurs. Création: 15/juin/07 14:22  Mise à jour: 03/sept./08 14:10

Etat: Ouvert
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Jérémie Bennejean Attribution: Sébastien Raguet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Il faut surveiller le fichier de conf /etc/postfix/main.cf
Et voir si tous sont identiques.

 Commentaires   
Commentaire de Ange Ferrari [ 14/sept./07 16:28 ]
Je veux bien mais je crois qu'il va falloir faire quelque chose :)


amphitrite
ec5284b40783ebb89c69607c6f760b55 /etc/postfix/main.cf
amphore
d038cc36ad95d0a1af1597c4a865b834 /etc/postfix/main.cf
angita
bb4b844699297f0b04af56500f981e3b /etc/postfix/main.cf
aricia
4030683f1988c5a3b45f8c39ded098e6 /etc/postfix/main.cf
aurore
bc6aa751fec4e4f8c809319c097fe197 /etc/postfix/main.cf
bacchus
860bd76cc2c95e86cedabe0148b3f7c9 /etc/postfix/main.cf
critias
6899c03e333c556875d2e4cd376103cc /etc/postfix/main.cf
cupidon
fc393f1b0361076dcf3a9f59d57f4154 /etc/postfix/main.cf
esculape
5b5885d133ec39dafbb90afb0d488f59 /etc/postfix/main.cf
evandre
22b1b9443da551906e370b046c95305a /etc/postfix/main.cf
graces02
c9c365590362df8cf2f9799bf1bf38dd /etc/postfix/main.cf
hercule
c46317d70af4d89cb83670130791a53e /etc/postfix/main.cf
janus
71652f647c456bd958cbd53622e9306e /etc/postfix/main.cf
junon
ddab4788753d7c9db9d90ccae12b533e /etc/postfix/main.cf
jupiter
1e4ad2d463edc8d2fb23b192640d95bc /etc/postfix/main.cf
latone
a6cd5fcb8e51fb3f2cffe7063ddb9290 /etc/postfix/main.cf
lykeia
9adf02051da61835196e5fc6e1c10f31 /etc/postfix/main.cf
mercure
138f7f88b7c24bccdc1b2050fc1c6ec5 /etc/postfix/main.cf
neptune
4a44ce120bf191f24e0490847264b61c /etc/postfix/main.cf
orcus
809bec1aa114b8a3fc1227f3c7c1b4c1 /etc/postfix/main.cf
pallas
0a3d3bf1d72c0a98cb001d775ebdd563 /etc/postfix/main.cf
parques
fb2ae2d040caf9ad56f90c8d9dc82964 /etc/postfix/main.cf
pelasgos
1b0a32c0a581398d9736566d549407b8 /etc/postfix/main.cf
phaeton
82b17d237794079c3127aeeaeaaae1a8 /etc/postfix/main.cf
rhome
20c485e462e3d11d20a178871ac87a7f /etc/postfix/main.cf
salus
93d3c9a6b5e3db710d131015ed25ae74 /etc/postfix/main.cf
saturne
81c4aadfb371a52464c14c2244014ee3 /etc/postfix/main.cf
sol
69960a6a0baf6b2682ad45c5eacb6dce /etc/postfix/main.cf
tellus
a8b7293626af327da42a8b183c38971a /etc/postfix/main.cf
terra
fdd242191fb70b825942e79ca45bedca /etc/postfix/main.cf
timee
ed3bebca31f48add9d4a49035b507d9b /etc/postfix/main.cf
titan
83dd4253cdb4d2deb496bcbbb66c7fb4 /etc/postfix/main.cf
titeia
b1bce9afa869227a4f95b3790830eb46 /etc/postfix/main.cf
venus
85cc7c5f06acfa8912e9da79945eb923 /etc/postfix/main.cf
Commentaire de Jérémie Bennejean [ 06/nov./07 18:44 ]
Ok la surveillance du /etc/postfix par le biais d'un md5sum ne fonctionnera pas du fait que tous ces fichiers ne seront jamais identiques puisqu'il comporte le nom du host sur lequel ils sont.




[BIN-429] [Sales] : Ajout de dimensions dans la base "FRANCE - ADVERT" (ean et identification fabricant) Création: 14/avr./08 14:01  Mise à jour: 15/mai/08 15:22  Résolue: 29/avr./08 10:22

Etat: Fermé
Projet: Business Intelligence
Composants: Sales
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Benjamin Guerville Attribution: Florian Ambrosi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel pro.xls    
Pays:
FRA - France

 Description   
Bonjour,
afin de pouvoir générer des export d'inventaire sans passer par les services de l'équipe param et donc gagner du temps, pourriez-vous rajouter les dimensions suivantes dans la base "FRANCE - ADVERT", répertoire "Product" :
- EAN
- Identification fabricant

MErci
BG

 Commentaires   
Commentaire de Agathe Remy [ 15/avr./08 15:08 ]
Benjamin,

Ces informations ne sont pas encore accessibles dans BI parce que non alimentées.
En effet, nous construisons au fur et à mesure une base orientée analyse sur laquelle BusinessObjects effectue ses requêtes. Or toutes les données du site ne s'y trouvent pas encore.
Notamment, en raison de l'important projet "Sauvons la base produit", nous avons choisi d'attendre que le modèle de données soit stabilisé avant de l'importer dans BI.
Ainsi, nous sommes aujourd'hui dans l'incapacité de vous fournir des informations telles que l'ean ou l'identification du fabricant.

Mettre à votre diposition ces informations dans BI représentant donc plusieurs jours de développement, il faut nous fournir une justification business pour pouvoir prioriser cette demande.

Merci.

Agathe
Commentaire de Agathe Remy [ 14/mai/08 15:36 ]
Listing des pros classés par nombre d'annonces décroissant




[IMP-2438] export producd Création: 10/juil./08 15:17  Mise à jour: 30/oct./09 15:42  Résolue: 10/juil./08 16:02

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Jany Marimoutou Attribution: Fotigui Tangara
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: producd
Séparateur: Point-virgule (;)
Type de traitement:
N/A

 Description   
besoin d'une extraction de son inventaire calqué sur la demande PRM-6017
Ne pas oublié la colonne "date de création"

Merci

 Commentaires   
Commentaire de Fotigui Tangara [ 10/juil./08 16:02 ]
Il faudra voir avec Agathe côté BI. Nous ne gérons plus les extractions de stocks. Merci
Commentaire de Fotigui Tangara [ 10/juil./08 16:02 ]
Je ferme la demande.




[APP-17094] case abonnement 24h décochée pour les personnes inscrites Création: 16/juil./07 12:27  Mise à jour: 22/mars/10 11:40  Résolue: 24/févr./10 16:15

Etat: Fermé
Projet: Application PriceMinister
Composants: News Letters
Affecte la/les version(s): 15.0.2
Version(s) corrigée(s): 65.0.0 (TX-M)

Type: Bogue Priorité: Mineur
Rapporteur: Alexandra Viravaud Attribution: Arnaud Forgues
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel abonne_24h.csv    
Liens des demandes:
Similaire
similaire à APP-17095 desabonnement newsletters - cobrandin... Fermé
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***

 Description   
Page Mes Abonnements (mise en ligne la semaine dernière) :

La case d'inscription aux mails 24h n'est pas cochée pour les personnes effectivement abonnées à cette offre partenaire alors que les personnes concernées continuent bien recevoir les news.
Pouvez-vous corriger ca ?
Merci
Alexandra

 Commentaires   
Commentaire de Arnaud Forgues [ 16/juil./07 14:25 ]
Alexandra, pourrais-tu préciser le login du compte concerné par ce bug ? Merci
Commentaire de Alexandra Viravaud [ 16/juil./07 14:53 ]
tequila2 (alex) ou delnaga (thomas).
PS : je viens de remarquer que le BO ne tient pas non plus compte des personnes abonnées à l'offre 24h :(
Commentaire de Arnaud Forgues [ 16/juil./07 15:23 ]
tequila2 est bien inscrit à 24h en BO comme en FO sur la page "Mes abonnements". Pour delnaga, ce compte n'existe pas en PROD ... ;-(
Commentaire de Alexandra Viravaud [ 16/juil./07 16:11 ]
un autre exemple (qui devrait marcher cette fois-ci) : bichdao
Commentaire de Arnaud Forgues [ 16/juil./07 16:29 ]
si je résume, quand je m'abonne à la news 24h, cela apparait bien en BO comme en FO et sur le compte "bichdao" cela n'apparait ni en BO ni en FO alors qu'elle recoit des news de 24h.

A priori, je dirais que c'était déjà le cas avant la refonte des abonnements, car on n'a rien changé à ce niveau. Et étant donné que tout à l'air de bien fonctionner pour les nouveaux comptes créé ainsi que pour les modifications d'abonnements, j'ai l'impression qu'il ne s'agit que de certains comptes qui se sont abonné à 24h au tout début du lancement ou qqch comme ça ... quoi qu'il en soit il n'y a aucun évenement lié à l'abonnement à la news 24h dans ce compte ni dans celui de "tequila2" ..

Du coup, je ne pense pas que ce JIRA soit critique ... et ensuite je ne vois pas trop comment je pourrais identifier les compte qui recoivent la news 24h alors qu'ils ne sont pas abonnés chez nous...

Ce qu'il nous faudrait c'est par exemple que le partenaire (24h) nous envoie le listing de tous les comptes (adresses emails) inscrits chez eux par notre biais afin que l'on resynchronise le tout

Passe me voir si tu veux qu'on en discute :D
Commentaire de Arnaud Forgues [ 24/juil./07 19:03 ]
en PJ, le fichier de tous les abonnés à 24h via PM. Mais seuls les utilisateurs avec le code 1394 se sont inscrits via le formulaire d'inscription ou "Mes abonnements" PM.

Il faut donc comparer cette liste aux véritables inscrits à PM en interne et faire éventuellement un script pour synchroniser le tout !
Commentaire de Emeric Teil [ 24/févr./10 16:15 ]
24h n'existant plus, je crois qu'on peut fermer :o)




[APP-20669] réponse automatique post-vente dvdlegacy Création: 27/mai/08 17:32  Mise à jour: 10/juil./09 10:32  Résolue: 09/juil./09 14:47

Etat: Fermé
Projet: Application PriceMinister
Composants: Back-Office
Affecte la/les version(s): 22.1.1
Version(s) corrigée(s): 49.0.0 (TX-H)

Type: Bogue Priorité: Majeur
Rapporteur: Natalia Calero Attribution: Cedric Favero
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne
Site: Prod
Projets PM: *** RESERVE ***

 Description   
sur le site espagnol, besoin d'une réponse automatique pour toute question post-vente aux Vendeurs :

dvdlegacy_es
dvdlegacycd
Legacybooks

la réponse doit être :

"Este mensaje es automático: A causa del gran número de pedidos que tramitamos diariamente, te agradecemos que para cualquier duda, te pongas en contacto directamente con PriceMinister a partir de la página de Contacto"

Voir la possibilité de pouvoir choisir de faire (depuis le b.o.) ça avec d'autres vendeurs qui ne parlent pas espagnol et/ou qui ne répondent pas systèmatiquement aux messages.


 Commentaires   
Commentaire de Charles Decaux [ 04/juin/08 09:35 ]
Hello,

cette demande est très importante afin d'améliorer la satisfaction acheteur. En effet, legacy génère plus de la moitié des ventes et ne répond pas aux questions post-achat.

Je pense qu'il faudrait également ajouter dans ce mail un lien direct vers le formulaire de contact du SAV.

Merci et à votre dispo pour en parler

Charles
Commentaire de Cantoni Carlos [ 04/juin/08 09:48 ]
cette demande est aussi a prévoir pour le site français ou nous avons le même probleme avec ce vendeur.

merci
Commentaire de Gaël Seguillon [ 04/juin/08 09:59 ]
Ce serait bien de le faire aussi pour les comptes sur le site Français qui sont dans la même situation de questions poste ventes multiples en attente
les pseudos de legacy sur la France
dvdlegacy
dvdlegacy_cd
legacy_books

Texte en français à transmettre dans les emails

Ceci est un message automatique, suite au nombre important de commandes reçues chaque jour le vendeur ne peut répondre aux questions directement, pour une réponse lié à un achat sur ce compte merci de prendre contact directement avec PriceMinister à partir de la page de contact (?) ou (suivi de commande : contactez PriceMinister)(?)
Commentaire de Steven Harel [ 04/juin/08 11:06 ]
natalia, peux-tu demander à christophe garcia de te donner les droits pour que des jiras te soient assignés ?
en attendant, je réassigne le jira à rocio

1/ je trouve très bizarre le fait de laisser la possibilité aux acheteurs de poser des questions pour leur dire qq minutes plus tard que le vendeur ne répondra pas. donc soit on bloque les questions post vente en back office comme on le fait pour les questions pre vente, soit on y répond.

2/ avant de décider quoi que ce soit, peut-on avoir une idée du type de questions posées ? s'il s'agit de problèmes sur une transaction, de questions sur le fonctionnement du site, ...

une fois qu'on aura une idée du type de questions en attente, on pourra décider de ce qu'on fait.

pour augmenter la satisfaction des utilisateurs (spécialement important pour l'espagne), je serais a priori d'avis de répondre nous-même aux questions (avec l'accord de dvdlegacy). on pourra alors rassurer les acheteurs, transformer les questions en réclamations si nécessaire, éviter les impayés, avoir une idée plus précise de l'état d'esprit des acheteurs, ...

nous avons actuellement 37 questions en attente, ça ne représente donc pas énormément de boulot.

Commentaire de Gaël Seguillon [ 04/juin/08 11:10 ]
les questions sur le compte français portent principalement sur délais d'expédition et la confirmation de l'expédition mais il n'y répond jamais
Commentaire de Steven Harel [ 04/juin/08 11:24 ]
pour ce genre de demande qui implique des procédures back office + d'éventuels développements, merci de mettre systématiquement cédric en observateur.

aucune décision ne sera prise sans son accord.
Commentaire de Natalia Calero [ 04/juin/08 12:09 ]
je confirme que sur le site espagnol les questions sont toujours des demandes de confirmation d'expédition, des messages confirmant la non réception des articles ou des messages qu'ils croient être des réclamations en non-reçu. donc monothematique. sauf rarement des précisions sur l'article.
Commentaire de Rocio Perez-Garcia [ 04/juin/08 16:33 ]
À étudier en COSAV
Commentaire de Cedric Favero [ 16/juin/08 18:00 ]
Malheureusement le premier lot des demandes COSAV étant passé, cette demande ne pourra etre traitée par ce biais rapidement si elle nécessite un developpement.
De plus il ne semble pas évident qu'on accepte un développement s'il n'est pas également justifié pour la France (ex: bloquer pour un compte les questions post/ventes et remplacer par un formulaire contact...)

On peut dans l'attente:
- répondre nous-même aux questions posées, eventuellement même par un message standard à définir.
- ajouter des infos spécifiques à ce vendeur dans les mails "bilan de commande" comme on le fait actuellement pour todoslibros.
- au pire , ajouter des infos spécifiques à ce vendeur dans le mail " pas de réponse à votre question" (on envoie pas de mail après l'envoi de la question elle-même)





Commentaire de Cedric Favero [ 16/juin/08 18:01 ]
je pense qu'il faut que vous en rediscutiez en réunion Espagne.
Commentaire de Charles Decaux [ 18/juin/08 10:15 ]
Vu avec Natalia, on est ok pour ces deux possibilités :

- soit pouvoir bloquer les questions post ventes comme on peut le faire aujourd'hui pour les questions pré-ventes.
En ajoutant un édito qui propose de contacter directement PriceMinister.
- soit envoyer automatiquement un mail à la suite d'une question post-vente indiquant que le vendeur ne répondra pas, mais que l'utilisateur peut contacter PriceMinister.

Concernant la France, le besoin existe également, particulierment sur les comptes de legacy (vu et discuté avec Gaël)..

Temporairement, on peut répondre au messages manuellement, mais ce n'est pas viable à long terme quand on aura plus de volume.

Merci et à votre dispo pour en parler.
Commentaire de Cedric Favero [ 18/juin/08 16:17 ]
Ok on part donc sur une solution dev , le besoin existant aussi pour la France.
On considère comme acceptable dans l'attente de répondre manuellement aux questions posées?

Concernant les solutions:

" soit envoyer automatiquement un mail à la suite d'une question post-vente indiquant que le vendeur ne répondra pas, mais que l'utilisateur peut contacter PriceMinister. "

=> Pas utile de laisser envoyer un mail si c'est pour lui dire que vendeur va pas y répondre
     Besoin n'existe pas par ailleurs d'avoir un mail envoyé après chaque question posée


"soit pouvoir bloquer les questions post ventes comme on peut le faire aujourd'hui pour les questions pré-ventes.
En ajoutant un édito qui propose de contacter directement PriceMinister. "

=> Meilleure solution car besoin existe aussi sur FR pour certains comptes pro.
     Consisterait donc en une case à cocher (plutot par le commercial que le pro lui-meme) qui interdirait les post-ventes pour le compte avec eventuellement un texte expliquant que le vendeur ne répond pas aux questions et que l'utilisateur doit contacter PriceMinister directement.

On va donc pousser cette demande dans le cadre du COSAV pour FR comme ES


Commentaire de Natalia Calero [ 18/juin/08 17:08 ]
Je confirme la nouvelle procédure temporaire mise en place depuis aujourd'hui :

La personne chargé de faire l'Espagne (Juan, Rocío et moi selon le jour) répondra aux questions post-vente posées aux comptes

dvdlegacy_es
dvdlegacycd
Legacybooks

avec la réponse type:

******
Debido a un incremento en nuestra actividad, no vamos a poder contestar a tu mensaje.

Si tu pregunta está relacionada con el envío o los plazos de entrega, te confirmamos que puedes hacer una reclamación a partir de tu cuenta. Para ello, debe haber pasado un mes desde la fecha de compra. Te recordamos que el plazo máximo para efectuar una reclamación es de 6 semanas.

Si tu pregunta es referente a otros temas, te agradecemos que contactes con PriceMinister a partir de la página de "contacto" indicando el número de la transacción.
******

Je n'hésiterai pas à commenter le jira si la tâche devient ingérable.
Commentaire de Cedric Favero [ 19/juin/08 15:30 ]
Pour plus de lisibilité pour les dev , j'ai créé un sous-JIRA: APP-20904.
Demande portant donc sur le fait de pouvoir bloquer en BO les questions post/ventes pour un compte donné.
Commentaire de Cedric Favero [ 08/juil./09 13:32 ]
DvdLegacy étant mort, on peut fermer cette demande.

La fonctionnalité pour refuser les questions post-ventes existent, il faut simplement modifier les pages et éditos lorsque celle-ci est activée. (demande COSAV identifiée bientot priorisée)




[APP-17301] Supprimer l'ancienne table FRIEND_MAIL Création: 26/juil./07 10:55  Mise à jour: 02/oct./07 18:01  Résolue: 28/sept./07 10:42

Etat: Fermé
Projet: Application PriceMinister
Composants: Parrainage
Affecte la/les version(s): 17.0.0
Version(s) corrigée(s): 17.0.0

Type: Tâche Priorité: Mineur
Rapporteur: Alexandre Garnier Attribution: Alexandre Garnier
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM archivés: Parrainage (refonte)

 Description   
Supprimer la table FRIEND_MAIL qui est devenue obsolète.

 Commentaires   
Commentaire de Alexandre Garnier [ 03/sept./07 15:55 ]
On la supprime comme ça ou on l'archive ou elle l'est déjà avec la base du BI ou la table sponsorship (qui contient les anciennes lignes de friend_mail) suffit ?
Commentaire de Quentin de Chivré [ 21/sept./07 11:11 ]
A mon sens le fait qu'on a migré dans la nouvelle table suffit.
On peut donc tout dropper.

Commentaire de Alexandre Garnier [ 28/sept./07 10:42 ]
V17_0_0_APP-17301_ALL_drop_friend_mail.sql




[BIN-456] Donner accès au rapport "Buyers distribution by purchase count" à Natalia Création: 06/juin/08 16:22  Mise à jour: 09/juin/08 11:23  Résolue: 09/juin/08 11:23

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Charles Decaux Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello,

Natalia travaille sur certaines problématiques de fidélisation sur l'Espagne. Dans ce cadre, elle a besoin d'accéder au rapport "Buyers distribution by purchase count" qui se situe dans mon dossier.

Pouvez-vous faire en sorte qu'elle puisse y accéder ?

Merci

 Commentaires   
Commentaire de Agathe Remy [ 09/juin/08 11:23 ]
Je pense qu'il suffit de prendre le temps de montrer à Nathalia comment accéder à BI via le user ur marketing.

Agathe




[IMP-2797] Correction Name Space - pseudo electropromo - Renseigner le name space sur les 1600 FP de son inventaire Création: 30/oct./08 13:58  Mise à jour: 30/oct./09 15:42  Résolue: 03/nov./08 18:53

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Frederic vacher Attribution: Frédéric Nahum
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: electropromo
Séparateur: Point-virgule (;)
Type de traitement:
N/A

 Description   
Bonjour,

Dans le fichier d'electropromo, il n'y a pas le namesapace ce qui bloque les imports de tous les autres partenaires.

Vu avec F.Nahum, nous allons faire une extraction de stock avec id product - Titre et référence fabricant pour pouvoir renseigner les Namespace.

Tous les titres des FP ont la même structure : Fabricant - type de produit Modèle. Avec l'extraction de stock ont pourra donc prendre tous les fabricant et les migrer vers les name space grâce à l'ID product.

 Ex : La Sommeliere - Cave à vin VIP180

Merci.

Fred

 Commentaires   
Commentaire de Frédéric Nahum [ 30/oct./08 16:41 ]
OK j'attend donc l'extraction de stock
Commentaire de Gaël Seguillon [ 30/oct./08 19:23 ]
Fred en fait je n'ai pas la possibilité par le BI de faire cette extraction de fiches produits, car je ne peux que ressortir les fiches pour lesquelles il a une annonce active celà ne donne pas la liste des produits créés par lui sans annonce ou ne garanti pas que toutes les fiches produit sur lesquelles il a une annonce ont été créées par lui il nous faut un extract dans le process habituel où au niveau du param vous faites une requête sur la base pour identifier toutes les fiches produits créées par ce pseudo
a ta dispo si ce n'est pas clair
merci
Gael
Commentaire de Frédéric Nahum [ 31/oct./08 15:38 ]
ok je vais essayer de me debrouiller
Commentaire de Frédéric Nahum [ 03/nov./08 18:53 ]
c'est fait j'ai rajouter le namespace pour les fiche produits de electropromo, elle devrait pouvoir etre reutilise pas d'autre partenaire




[APP-21810] Il manque des brouillages de liens du coté www.priceminister.com/help/ Création: 20/août/08 12:06  Mise à jour: 07/janv./09 16:41  Résolue: 07/janv./09 16:41

Etat: Fermé
Projet: Application PriceMinister
Composants: Aide en ligne, Référencement
Affecte la/les version(s): 27.0.1.2
Version(s) corrigée(s): 38.0.0 (TX-D Bis)

Type: Amélioration Priorité: Majeur
Rapporteur: Pierre Bret Attribution: Christophe Garcia
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Liens des demandes:
Duplicate
a pour doublon APP-23865 Brouiller liens externes dans les pag... Fermé
Similaire
similaire à APP-22721 Un lien externe ouvert dans l'aide Fermé
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-23865 Brouiller liens externes dans les pag... Sub-bug Fermé Olga Costa  
Pays:
ALL - Tous
Site: Prod
Projets PM: *** RESERVE ***
Classif FONC: ref

 Description   
Les pages suivantes comportent des liens non brouillés :
http://www.priceminister.com/help/h
http://www.priceminister.com/help/fv
http://www.priceminister.com/help/h_principle
http://www.priceminister.com/help/hs
http://www.priceminister.com/help/hb
http://www.priceminister.com/help/hw
http://www.priceminister.com/help/c

N'hésitez pas à nous solliciter pour plus d'info

 Commentaires   
Commentaire de Cedric Favero [ 20/août/08 15:31 ]
Euh personnellement , çà ne me parle pas du tout.
Swan ou Alexandre , c'est vous qui gérez çà?
Ou c'est quelquechose qu'on a pas fait correctement dans infoglue?

Merci.
Commentaire de Swan Desportes [ 20/août/08 17:28 ]
On n'a jamais brouillé les liens dans l'aide.
C'est une nouveauté.
C'est à nous de gérer ça.
Commentaire de Pierre Bret [ 23/oct./08 14:07 ]
Et 3 mois plus tard, où en est cette demande ?
Commentaire de Pierre Bret [ 23/oct./08 14:08 ]
En fait ça fait 2 mois .. je sais :)

Le lien externe est sur :
http://www.priceminister.com/help/hb_vehicle
Commentaire de Alexandre Garnier [ 24/oct./08 10:47 ]
Quasi impossible (et risquerait d'être super lourd) de brouiller automatiquement les liens présents dans l'aide.
Normalement on se posait pas ce problème car c'était les accès à l'aide qui sont brouillés.

Si on veut les brouiller, il va falloir le faire à la mano en passant sur chaque contenu de l'aide pour appeler la méthode de brouillage (et compliquer encore plus la navigation des utilisateurs avec des liens JS...)
Commentaire de Pierre Bret [ 24/oct./08 11:13 ]
ok, merci pour ces infos

Vu l'origine de la demande, je pense qu'il va falloir se les faire un par un à la mano comme tu dis.

Qui est en charge de ces pages là ?
Commentaire de Cedric Favero [ 24/oct./08 12:04 ]
C'est nous au BO qu gérons ces pages mais j'aimerais bien qu'on ne complique pas inutilement tout çà si pas réellement nécessaire.

"Normalement on se posait pas ce problème car c'était les accès à l'aide qui sont brouillés. "
=> Et ce n'est plus le cas?
Commentaire de Thierry Leforestier [ 24/oct./08 12:09 ]
C'est toujours le cas, mais nous savons que Google connait les urls par d'autres biais (liens externes etc.) c'est donc pour cette raison que nous ne voulons pas créer une navigation alternative dans l'aide.

De plus, la demande émane du Coex...
Commentaire de Cedric Favero [ 24/oct./08 12:11 ]
Ben dites moi ce que vous envisageriez de faire et on en parle..
En sachant qu'on est bien obligé de faire des liens...
Commentaire de Thierry Leforestier [ 24/oct./08 12:13 ]
Pas de soucis avec le fait de faire des liens, c'est simplement qu'il faut les brouiller pour éviter le passage de Google sur les pages liées et une transmission de PageRank inutile.

Je pense qu'un rapide point serait nécessaire en début de semaine. J'organise ça.

Thierry
Commentaire de Cedric Favero [ 28/oct./08 18:01 ]
Un certain nombre de demandes arrivent chez nous pour modifier les formats de liens dans l'aide (afin de les brouiller) en suivant la méthode indiquée dans le WIKI.

Tout çà est assez lourd et peut etre facilement source d'erreurs.

La question est la suivante: est-ce qu'on ne peut pas integrer ce format de lien , s'il est privilégié , directement dans l'éditeur WYSIWYG d'Infoglue?

Merci.
Commentaire de Cedric Favero [ 28/oct./08 18:04 ]
Ne pas tenir compte de mon précédent message.
Puisque çà ne concerne que les liens externes , aucune utilité à la généraliser..

On fait donc à la mano pour ces cas là.
Commentaire de Alexandre Garnier [ 03/nov./08 16:02 ]
Petite question : quand vous brouillez les liens à la mano, vous faites quoi ?
Parce que théoriquement il devrait vous suffire d'appeler $LinkFormat ou d'utiliser les macros velocity, jamais de brouiller vous-même les liens.
Commentaire de Cedric Favero [ 03/nov./08 17:19 ]
Ben jusqu'à present on ne faisait rien. On va regarder le Wiki que tu as indiqué.
Commentaire de Cedric Favero [ 03/nov./08 17:57 ]
Donc si on veut faire un lien externe vers www.machin.com , il faut faire comme çà ?:

$LinkFormat.finalUrl('www.machin.com ', 'win')
Commentaire de Alexandre Garnier [ 03/nov./08 18:04 ]
Exactement.
Commentaire de Alexandre Garnier [ 13/nov./08 18:50 ]
cf jira lié APP-22721 pour plus de détail/explication sur le brouillage.
Commentaire de Cedric Favero [ 13/nov./08 19:23 ]
Habib est en train de repasser sur un tout çà et on en a indentifié meme plus.

Par contre , question, quid de tous les liens vers Wengo?
Est-ce qqch qu'il faut brouiller aussi?
Commentaire de Fabrice Feugas [ 13/nov./08 19:29 ]
Oui il faut les brouiller.

On avait défini cette règle pendant le projet de mise en avant wengo, mais nous ne l'avions pas appliquée pour l'aide en partant du principe que "les accès à l'aide étaient brouillés".
Commentaire de Thierry Leforestier [ 14/nov./08 09:19 ]
Je confirme.

Thierry
Commentaire de Cedric Favero [ 14/nov./08 09:26 ]
OK c'est noté.
On en fait passer une premiere partie rapidement et habib continue sur le reste...
Commentaire de Thierry Leforestier [ 25/nov./08 14:47 ]
Savez-vous quand on aura les bons liens pour AssurOne sur cette page :
http://www.priceminister.com/help/h_insurance_offer

Ne pas oublier de les brouiller également.

Thierry
Commentaire de Thierry Leforestier [ 25/nov./08 14:48 ]
Peut-on même le brouiller maintenant ce lien assurOne ? ca ne sera plus a faire :)

Merci
Commentaire de Cedric Favero [ 25/nov./08 15:43 ]
On peut effectivement brouiller déjà ce lien (cassé de toute façon) , meme si mauvais et on le changera dès qu'on aura le bon lien.
Commentaire de Habib-Sylvain Gourguet [ 25/nov./08 16:01 ]
D'après Lorenzo, le partenariat de PM Auto avec AssurOne n'a plus cours (depuis près d'un an). Le partenaire de PM Auto est désormais AssurLand (voir http://www.priceminister.com/info/assurance).

Le contenu de cette page est donc obsolète. Il est également prévu que la Technique de PM Auto soit bientôt gérée par Mixad, sauf erreur de ma part.

On trouve encore des liens en FO qui dirigent vers ce contenu ?
Commentaire de Habib-Sylvain Gourguet [ 10/déc./08 15:10 ]
Je soumets à publication les derniers contenus comportant des liens qui redirigent vers des sites externes.

Contenus modifiés sous CMS1.
Commentaire de Cedric Favero [ 12/déc./08 09:27 ]
egalerment fait sur UK
publié sur cms1
Commentaire de Christophe Garcia [ 07/janv./09 15:16 ]
Peut-on avoir une liste des pages modifiées.
Pour info, dans la page /info/assurance, les liens ne sont toujours pas brouillés.
Voir screenshot
Commentaire de Thierry Leforestier [ 07/janv./09 15:28 ]
Oui, il faut absolument qu'ils soient brouillés !

Thierry
Commentaire de Cedric Favero [ 07/janv./09 15:46 ]
Les pages /info sont gérées par le param.
Commentaire de Cedric Favero [ 07/janv./09 15:47 ]
Pour la liste de tous les liens modifiés , je ne pense pas qu'on ait noté tout çà.
Il y avait qques liens vers les sites des impots ou des choses comme çà..
Habib de memoire?
Commentaire de Habib-Sylvain Gourguet [ 07/janv./09 16:34 ]
J'ai une liste non exhaustive des contenus modifiés :

i_vehicle_refund_contract_detail
h_offer_launch
i_chrono_label
i_no_shipping
h_external_service_planetanoo
h_insurance_offer
auto_alias_1_11_4_2
auto_alias_1_6_6
cs_op_double
i_pro_acc_adv
new_offer_launch
auto_alias_5_35_2_12_2
auto_alias_5_35_1_6_3
auto_alias_5_35_2_12_1

Manque la vingtaine ou trentaine de formulaires de contact sur www comportant des liens vers Wengo...

Et depuis ce JIRA, je brouille la totalité des liens qu'il m'est possible de brouiller :)




[EXP-4435] Extraction de logs Création: 07/juil./08 10:43  Mise à jour: 07/juil./08 11:44  Résolue: 07/juil./08 11:44

Etat: Résolu
Projet: Exploitation
Composants: Etude
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Thierry Leforestier Attribution: Patrice Boulanger
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Nous aurions besoin pour le marketing d'une extraction des derniers logs (sur 2 ou 3 jours) avec tous les codes HTTP (200, 3xx, 4xx, 5xx) selon les critères suivants :
referrer contenant google
url contenant "t="

Merci d'avance,

Thierry

 Commentaires   
Commentaire de Thierry Leforestier [ 07/juil./08 11:44 ]
Nous avons trouvé d'où vient le problème lié aux données du BI. Inutile donc de faire l'extraction.

Thierry




[APP-21775] [Widget parrainage] Création d'une page d'aide sur le Widget parrainage Création: 14/août/08 11:40  Mise à jour: 08/sept./08 11:18  Résolue: 29/août/08 17:45

Etat: Fermé
Projet: Application PriceMinister
Composants: Aide en ligne
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 28.0.0 (CTN-F)

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Rocio Perez-Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à APP-21774 [Widget parrainage] Création d'un art... Fermé
Pays:
ESP - Espagne, FRA - France
Projets PM: *** RESERVE ***

 Description   
Ajouter une page "Question sur le Widget Parrainage" dans la page Contact/ questions sur le parrainage:
http://www.pm.lan/help/c#contact_sponsorship

(sera reprise également par un lien "questions frequentes" dans la page "mes filleuls" )

 Commentaires   
Commentaire de Cedric Favero [ 14/août/08 11:48 ]
également une page pour lien sur le compteur "filleuls recrutés via Widget"
Commentaire de Cedric Favero [ 19/août/08 17:00 ]
Ok, sont donc créées les pages suivantes:

http://www.pm.boulard:1580/help/c_sponsorwidget (alias "c_sponsorwidget" )
Pour la page contact / question sur le Widget parrainage. Avec un formulaire éventuelleent pour question spécifique à cette nouvelle fonctionnalité.

http://www.pm.boulard:1580/help/i_widgetrecruited (alias "i_widgetrecruited" )
Pour le lien d'explication sur le compteur "Mes filleuls via blog"


Commentaire de Cedric Favero [ 19/août/08 17:02 ]
Seb , si tu as des retours...
J'attends de ta part l'URL de page de création du Widget.
Merci.
Commentaire de Cedric Favero [ 22/août/08 15:55 ]
On crée également une page pour popup expliquant comment insérer le code:

http://www.pm.boulard:1580/help/i_sponsorwidgetcode (alias "i_sponsorwidgetcode" )
Commentaire de Cedric Favero [ 29/août/08 09:40 ]
Une modif dans i_widgetrecruited:

ce n'est pas le nombre de filleuls qui est limité (les compteurs peuvent continuer à tourner meme si depasse 100)
=> c'est le nombre de coupons pour le parrain qui est limité.

On dit donc:

Le nombre maximum de coupons qui vous seront alloués grâce aux filleuls parrainés par ce biais est fixé à 100.

(on ne dit plus , en plus des 100 (ou 200) autres possibles..)
Commentaire de Rocio Perez-Garcia [ 29/août/08 09:50 ]
Vale, modifs faites je soumets a pub
Commentaire de Cedric Favero [ 29/août/08 17:45 ]
publié sur cms1
V28 CTN-F




[APP-18626] [OTM] Valeurs d'attribut impossible à fusionner Création: 21/nov./07 17:02  Mise à jour: 04/mars/08 15:33  Résolue: 15/févr./08 15:01

Etat: Fermé
Projet: Application PriceMinister
Composants: Back-Office
Affecte la/les version(s): 18.0.0
Version(s) corrigée(s): 19.2.0

Type: Bogue Priorité: Critique
Rapporteur: Fabien Farache Attribution: Matthieu Bene
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Text File EnsembleDeLogs.TXT     JPEG File screenshot-1.jpg    
Liens des demandes:
Dépendance
bloque CAT-123 Nettoyage valeurs attributs - Origine... Résolu
Similaire
similaire à APP-18842 Perf sql : /* MPTAttributeValueQuery */ Fermé
similaire à APP-19473 [BO] - Erreur lors d'une création (mo... Ouvert
similaire à APP-18842 Perf sql : /* MPTAttributeValueQuery */ Fermé
Pays:
FRA - France
Site: Integ
Navigateur: Tous
Projets PM archivés: OTM (Lot 2) - Valeurs d'attributs - Intégration

 Description   
Sur l'attribut PMA0000518 (Origine / Pays) lorsque nous voulons fusionner les 2 valeurs "France" la requête n'aboutie pas et nous n'avons pas de fichier soumis en import.

 Commentaires   
Commentaire de Matthieu Bene [ 04/déc./07 15:09 ]
NamedQuery interminable dans PrdAttribute :

name = "com.babelstore.stock.entity.PrdAttribute.findByAttributeValueKey",
queryString = " select prdAttribute from PrdAttribute prdAttribute" +
                         " where prdAttribute.prdAttributeValueKey = :prdAttributeValueKey "

2007-12-04 14:29:20 DEBUG [SQL ] BO:Anonyme -
    /* named HQL query com.babelstore.stock.entity.PrdAttribute.findByAttributeValueKey */ select
        prdattribu0_.PRD_ATTRIBUTE_ID as PRD1_5_,
        prdattribu0_.NUMERIC_VALUE as NUMERIC2_5_,
        prdattribu0_.PRD_TYPE_CODE as PRD3_5_,
        prdattribu0_.CONTRACT_ID as CONTRACT4_5_,
        prdattribu0_.PRD_ATTRIBUTE_DATE as PRD5_5_,
        prdattribu0_.ROW_VERSION as ROW6_5_,
        prdattribu0_.PRODUCT_ID as PRODUCT7_5_,
        prdattribu0_.PRD_ATTRIBUTE_VALUE_KEY as PRD8_5_,
        prdattribu0_.PRD_ATTRIBUTE_UNIT_KEY as PRD9_5_,
        prdattribu0_.PRD_ATTRIBUTE_NAME_KEY as PRD10_5_,
        prdattribu0_.CREATION_DATE as CREATION11_5_,
        prdattribu0_.CHANGE_DATE as CHANGE12_5_
    from
        PRODUCT_1.PRD_ATTRIBUTE prdattribu0_
    where
        prdattribu0_.PRD_ATTRIBUTE_VALUE_KEY=?

2007-12-04 14:34:18 WARN [TransactionImpl ] - Transaction TransactionImpl:XidImpl[FormatId=257, GlobalId=boulard/27, BranchQual=, localId=27] timed out.status=STATUS_ACTIVE
Commentaire de Matthieu Bene [ 04/déc./07 15:09 ]
NamedQuery interminable...
Commentaire de Edouard Gomez-Vaez [ 05/déc./07 17:30 ]
Manu m'a dit que c'est difficilement corrigible tel quel.
--> Voir dans quels cas cette requête est appelée. Pourquoi en fusion aussi ?
Commentaire de Fabien Farache [ 24/déc./07 15:49 ]
même problème pour l'attribut "Livres / Langue" (PMA0000034) pour fusionner les valeurs "Français" (K81245) et "Français" (PMK0000243)
Commentaire de Fabien Farache [ 10/janv./08 13:36 ]
qu'a-t-il été fait ?

pouvons nous fusionner ce genre de valeurs via OTM dorénavant ?
Commentaire de Matthieu Bene [ 10/janv./08 14:15 ]
Les requêtes ont été changées. Sortie en en V19.0.0
Commentaire de Espérance Galouo-Lece [ 08/févr./08 09:59 ]
 - Le problème est toujours présent en demandant la fusion pour l'attribut "Livres / Langue" (PMA0000034) pour fusionner les valeurs "Français" (K81245) et "Français" (PMK0000243);
 - Cf. PJ.
Commentaire de Matthieu Bene [ 11/févr./08 12:43 ]
Requête de récupération des informations pour les fichiers d'import trop longue. Solution : exécuter une seule fois par mapping la requête (récupération des produits compléments et de base dans la même requête) et supprimer la jointure sur prd_attribute_value et prd_attribute_name. Les informations value et name pourront être récupérées par finder.
Commentaire de Matthieu Bene [ 11/févr./08 14:46 ]
La requête est implémentée dans MPTAttributeValueQuery :
public List getAttributeList(AttributeValueMappingInfo mapping, Boolean bIsComplement)

Elle est appelée dans l'action (MPTAttributeValueAction) par le biais du ProductCatalog :
public List<PrdAttribute> getAttributeList(List<AttributeValueMappingInfo> mappings, boolean bbIsComplement)
Commentaire de Matthieu Bene [ 12/févr./08 12:21 ]
Enlever la jointure sur prd_attribute_value et prd_attribute_name ne suffit pas...
Commentaire de Matthieu Bene [ 12/févr./08 18:40 ]
Récupérer les produits compléments et de base dans la même requête apporte une importante amélioration des performances. Cependant, la fusion de la valeur PMK0000243 vers K81245 pour le nom d'attribut PMA0000034 concerne près de 400.000 produits (plus de 300.000 rien que pour le type Livres). La transaction dans laquelle s'exécute la requête est marquée pour rollback au bout de 5 minutes, avant avoir ramené les produits du type Livres. Pour les fusions concernant un nombre important de produits, il faut donc migrer les produits directement en base et passer par l'outil après.
Commentaire de Fabien Farache [ 13/févr./08 09:48 ]
Comment pouvons nous savoir que des valeurs concernent un nombre important de produits quand le calcul de celui-ci n'abouti pas et génère une erreur ?
Commentaire de Matthieu Bene [ 13/févr./08 10:38 ]
La solution est d'effectuer une requête de comptage directement en base.
Commentaire de Christophe Garcia [ 14/févr./08 16:57 ]
Edouard, tu confirmes ?

Ca me paraît lourd à gérer côté PARAM non ?
Commentaire de Fabien Farache [ 14/févr./08 17:07 ]

1) Nous n'avons pas autorisation de requêter la base de prod mais juste la base de reporting

2) S'il faut toujours passer par un autre outil pour faire quelque chose ce n'est pas genial il faut bien l'admettre...
Mais fournissez nous les requêtes, ce sera déjà ça de pris :)
Commentaire de Edouard Gomez-Vaez [ 14/févr./08 17:13 ]
Nicolas, je confirme, malheureusement...

La requête simple (sans filtre sur type ou medium) est :
select count(prd_attribute_id)
from prd_attribute
where prd_attribute_name_key = 'clef du nom d'attribut'
   and prd_attribute_value_key = 'clef de la valeur d'attribut';

pour rajouter un filtre sur un type : rajouter un
and prd_type_code = 'code du type'

pour rajouter un filtre sur un medium c'est compliqué, mais faisable : venir me voir.

Fabien, cela te parait-il clair ?
Commentaire de Matthieu Bene [ 15/févr./08 15:01 ]
La requête de récupération des données pour les fichiers d'import de fusion de valeurs d'attributs a été modifiée ce qui apporte un gain important des performances.
Commentaire de Fabien Farache [ 15/févr./08 15:57 ]
pour les requêtes c'est clair
Commentaire de Edouard Gomez-Vaez [ 04/mars/08 15:31 ]
Quitte à revoir les exceptions traitons app-18626 et app-19473 en même temps pour éviter ce genre d'affichage.




[BIN-491] [Finance] : Rapport Payment by Purchase - Carte Quelle Création: 18/sept./08 15:12  Mise à jour: 17/oct./08 17:31  Echéance: 31/oct./08 00:00  Résolue: 17/oct./08 17:31

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Claudie Dufresne Attribution: Julien Girardet
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Dalila, Agathe,
Comme vu ensemble, les paiements effectués avec la nouvelle carte de paiement Quelle seront associés au type de carte "COFINOGA".
Dans le rapport "payment by purchase", pour permettre de distinguer les transactions effectuées avec la carte QUELLE de celles effectuées avec la carte COFINOGA, il est nécessaire d'ajouter dans le rapport une colonne reprenant les 4 premiers numéros de la carte.
(les numéros de la carte QUELLE commençant par 5032).
merci
claudie



 Commentaires   
Commentaire de Dalila Belkebir [ 17/oct./08 17:31 ]
Point avec Claudie le 16/10 : les infos comptables seront envoyés conjointement pour Quelle et Cofinoga (dans un même fichier).

=> Côté BI nous n'avons donc plus besoin de marginaliser les carte QUELLE parmi les Cofinoga.
Le JIRA est donc fermé puisqu''il n'y a rien à faire pour nous ....


Dalila.




[EXP-4110] Imprimante fraudes HS Création: 29/nov./07 15:13  Mise à jour: 10/avr./08 09:27  Résolue: 10/avr./08 09:27

Etat: Fermé
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Sebastien Bruzzone Attribution: Stéphane Eccli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Bonjour,

L'imprimante Brother MFC-8820D-printer a des problèmes d'impression depuis des semaines, les feuilles sont systématiquement noircies.
Jerome avait vu le problème et m'avait dit qu'il avait contacté une société pour réparer ce problème.

ça commence à devenir important car on reçoit des documents de clients et des réquisitions judiciaires et les papiers deviennent de plus en plus illisibles.

Merci.

Sébastien.

 Commentaires   
Commentaire de Sebastien Bruzzone [ 10/déc./07 11:42 ]
ça commence à urger, je reçois des papiers de clients et des réquisitions de plus en plus illisibles, ce qui commence à devenir très problématique...
Commentaire de Sebastien Bruzzone [ 28/déc./07 15:37 ]
Apparemment c'est un problème de cartouche, il faut commander des cartouches BROTHER DR3000

on est plusieurs à utiliser ce modèle là au backoffice, il faudrait en commander plusieurs

Steven confirme que c'est hyper urgent, nous recevons des documents important par le biais de ces imprimantes.
Commentaire de Steven Harel [ 28/déc./07 15:53 ]
je confirme l'urgence

la cartouche de sébastien a été maltraitée par jérome
celle de régis est presque vide

plus de fax pour les fraudes c'est plus la possibilité de recevoir des docs pour confirmer les grosses commandes !
Commentaire de Patrice Boulanger [ 28/déc./07 16:41 ]
J'ai fait une demande au commercial d'InMac pour commander 4 cartouches (2 pour MFC-8820D et 2 pour la HL-5130 de Régis). J'attend son retour ASAP.

Merci.
Commentaire de Patrice Boulanger [ 21/janv./08 16:33 ]
Les toners ont été reçus et installés.
Commentaire de Sebastien Bruzzone [ 22/janv./08 14:38 ]
ça ne marche pas même après le chargement de la cartouche, les impressions sont toujours noires
Commentaire de Jérémie Bennejean [ 28/févr./08 14:20 ]
Le fax de Sébastien est changé.
Une imprimante va être commandée lors de la prochaine commande DELL
Commentaire de Jérémie Bennejean [ 28/févr./08 14:20 ]
En attendant la nouvelle imprimante, il imprime sur celle du rdc.
Commentaire de Stéphane Eccli [ 10/avr./08 09:27 ]
Nouveau fax, impression sur le copieur, vu avec Steven




[PMV : Migration des Anciens Vendeurs] (APP-21971)

[APP-22047] Migration du lot 5 : Particuliers par virement avec un PMV activé, restreint ou bloqué Création: 05/sept./08 18:11  Mise à jour: 09/oct./08 11:32  Résolue: 02/oct./08 15:27

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 27.0.1
Version(s) corrigée(s): 31.0.0 (TX-C)

Type: Sous-tâche Priorité: Majeur
Rapporteur: Arnaud Forgues Attribution: Arnaud Forgues
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM archivés: Paiement - Migration anciens vendeurs

 Description   
Dans ce lot, on migre les utilisateurs particuliers actuellement en privilège SILVER (virement) dont le PMV a déjà été activé (sauf les vendeurs -2, qui par construction auront déjà été migrés dans le lot 1) en privilège Platine mode libre sans configuration des reversement du PMV.

Ces utilisateurs seront soumis à une communication par mail des changements liés à cette migration : en effet, ils devront alors configurer une demande de reversement ponctuelle ou régulière par virement afin de recevoir à nouveau les paiements de leurs ventes.

 Commentaires   
Commentaire de Arnaud Forgues [ 02/oct./08 15:27 ]
La migration est effective.

Le ciblage est en cours au BI et le mailing d'accompagnement sera envoyé samedi prochain.




[BIN-398] [Tracking] : Mise en place d'un reporting hebdomadaire pour Clubic Création: 21/déc./07 17:55  Mise à jour: 05/févr./08 15:15  Résolue: 08/janv./08 18:49

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Henrieta Bubenkova Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Je voudrais qu'en plus de l'appel mensuel à facture pour le tracking 1 "Clubix" les rapports hebdomadaires soient générés et envoyés avec une fréquence hebdomadaire à l'adresse de notre partenaire.

Merci d'avance
henrieta

 Commentaires   
Commentaire de Henrieta Bubenkova [ 07/janv./08 15:43 ]
Pourrais-tu juste encore ajouter à Clubicx le No de paniers dans les statistiques hebdomadaires stp ?
Nous pouvons envoyer les stats hebdo lundi et le 05 dsu mois pour le mensuel
merci!
Commentaire de Samir Beghdadi [ 08/janv./08 18:49 ]
Agathe,

Peux tu valider les spécifications (fonctionnel et technique) pour les rapports de Clubic qui se trouvent dans V:\Reporting\BusinessIntelligence\Evolutions\Clubic.
Et les rapports "Clubic - Appel à facture hebdomadaire" et "Clubic - appel à facture mensuel" qui se trouvent dans Public Folders/Development/Marketing/Purchase.

Si nécessaire les passer en prod avec une programmation chaque lundi pour l'hebdomadaire et remplacer l'actuel appel à facture Clubic chaque 5 du mois.

Merci :-)

Samir qui parts en vacance
Commentaire de Agathe Remy [ 28/janv./08 15:32 ]
Henrieta,

Les rapports "Clubic - Appel à facture mensuel" et "Partner - Weekly revenue by tracking group" ont été livré en Production dans le dossier public France/Purchase.

Peux-tu nous dire s'ils te conviennent? Dès que tu les auras validé, Samir pourra programmer leur envoi par mail au partenaire.

Merci.

Agathe

Commentaire de Henrieta Bubenkova [ 30/janv./08 14:52 ]
Je valide le format des rapport Clubicx (mensuel + hebdomadaire) qui se trovent sur BI/Dossiers Publics/Purchase
merci!
henrieta
Commentaire de Agathe Remy [ 30/janv./08 19:13 ]
Samir,

Il ne te reste plus qu'à désactiver l'ancien appel à facture et à programmer les 2 nouveaux rapports.

Merci:-)

Agathe
Commentaire de Samir Beghdadi [ 31/janv./08 12:52 ]
Les deux rapports sont programmés:

Pour l'hebdo c'est chaque lundi à 12h30 et pour le mensuel c'est comme l'ancien chaque 5 du mois à 8h00.

J'ai modifié le corps du mail du rapport hebdomadaire (remplacer "appel à facture du mois dernier" par " le Chiffre d'affaires généré la semaine dernière").

Merci

Samir




[BIN-427] [Tracking] : ajout d'un destinataire pour les appels à facturation mensuels Création: 07/avr./08 12:03  Mise à jour: 14/mai/08 15:24  Résolue: 15/avr./08 14:41

Etat: Fermé
Projet: Business Intelligence
Composants: Partners
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Henrieta Bubenkova Attribution: Florian Ambrosi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Suite à la demande de notre partenaire Pangora je voudrais ajouter un autre destinataire de l'appel à facturation mensuel comme suivi:

destinataire actuel: Nicolas Preteceille [Nicolas.Preteceille@pangora.com]

nouveau destinataire à ajouter: ariane.kliche@pangora.com

Merci
Henrieta


 Commentaires   
Commentaire de Romain Czornomaz [ 07/avr./08 12:10 ]
Florian,

Peux tu traiter la demande?

Merci d'avance,

Romain
Commentaire de Florian Ambrosi [ 07/avr./08 15:05 ]
Romain,

J'ai ajouté l'adresse email au destinataire de l'appel à facture mensuel Pangora, mais je crois avoir lancé la tâche par erreur.

Florian
Commentaire de Agathe Remy [ 15/avr./08 11:16 ]
Mail du 07/04 :
"Bonjour,

Pouvez-vous mettre Ariane Kliche (comptabilité) en copie de chacun des mails d'appels à factures (ariane.kliche@pangora.com) ?

En vous remerciant par avance
Cordialement

Nicolas Préteceille
Key Account Manager France
"
Commentaire de Agathe Remy [ 15/avr./08 11:18 ]
Henrieta,

Veux-tu que nous nous en occupions?

Agathe

Mail du 10/04 :
"Bonjour Henrieta,
Je vous remercie pour l'ajout d'Ariane Kliche dans la liste des destinataires.
Pouvez-vous me faire parvenir l'intégralité des appels à factures depuis Août 2007 ?
En vous remerçiant par avance
Cordialement
Nicolas Préteceille
Key Account Manager France"


Commentaire de Agathe Remy [ 15/avr./08 14:39 ]
Merci bcp Agathe, je l'ai déjà fait en leur envoyant les appels mensuels de
l'historique dans BI.
henrieta




[BIN-395] [Business Objects] Demande de filtre dans France-Purchase Création: 11/déc./07 17:59  Mise à jour: 17/déc./07 11:20  Résolue: 17/déc./07 11:20

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
FRA - France

 Description   
Serait-il possible d'ajouter dans France-Purchase un filtre pour savoir si un panier est passé en observation et s'il y a eu une confirmation manuelle.

A moins que j'ai mal regardé et que çà existe déjà.

Cf capture pour les deux états.


Merci.

 Commentaires   
Commentaire de Agathe Remy [ 17/déc./07 11:20 ]
Cette demande consiste à idenitifer les paniers capturés passés par les statuts OBSERVATION, puis confirmés manuellement.
Cela revient à restituer l'historique des évènements d'un panier. Ceci n'est actuellement pas possible via BI.

Cordialement,

Agathe




[APP-21774] [Widget parrainage] Création d'un article supplémentaire dans le reglement parrainage Création: 14/août/08 11:27  Mise à jour: 08/sept./08 11:18  Résolue: 29/août/08 17:44

Etat: Fermé
Projet: Application PriceMinister
Composants: Aide en ligne
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 28.0.0 (CTN-F)

Type: Amélioration Priorité: Majeur
Rapporteur: Cedric Favero Attribution: Cedric Favero
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word Ajout_parrainage(fraudes).rtf     Microsoft Word parrainage_widget.rtf     Microsoft Word spec_widgetparrainage_v0 6 (2).doc    
Liens des demandes:
Similaire
similaire à APP-21775 [Widget parrainage] Création d'une pa... Fermé
Pays:
ESP - Espagne, FRA - France
Projets PM: *** RESERVE ***

 Description   
Doit etre ajouté un article dans le reglement parrainage pour ce qui concerne le widget parrainage.

Indiquer que, comme pour les autres parrainages ,le parrain (et donc possesseur du widget) ne doit pas tenter de se parrainer lui-même.
Que ne seront validés les coupons que si les filleuls sont eux-même élligibles.
Que le nombre de filleuls maximum acquis par le widget est limité à 100 (compteur dispo sur son compte)

Je vois avec Benoit pour la rédaction de cet article.

 Commentaires   
Commentaire de Cedric Favero [ 14/août/08 11:28 ]
en PJ les derniers specs du projet
Commentaire de Cedric Favero [ 19/août/08 17:03 ]
Modif reglement par Benoit
Commentaire de Cedric Favero [ 19/août/08 17:44 ]
Plutot que créer un article supplementaire , je l'ai inclus dans l'article 3.
Ca me semble suffisant comme çà:

http://www.pm.boulard:1580/help/r_sponsorship
Commentaire de Cedric Favero [ 21/août/08 10:26 ]
Ok c'est bon , j'en ai profité pour ajouter les éditos demandés par les Fraudes.

Toutes les modifs de contenus sont dans l'Article 3 - Modalités de participation.
J'en ai aussi profité pour tous les articles pour changer les "auto-alias".

On verra ensuite si on change la structure (tous articles dans une meme structure) ( cf APP-20946)
Commentaire de Cedric Favero [ 21/août/08 10:27 ]
Rocio , c'est bon , tu peux traduire les modifs (article 3)
Merci.
Commentaire de Cedric Favero [ 25/août/08 14:30 ]
Pour info,
L'article 3 ne contient des infos sur le Widget parrainage que dans le content version WWW (car ne s'applique pas aux cobrandings)
Commentaire de Rocio Perez-Garcia [ 25/août/08 17:47 ]
Modifications faites sur ES. Je te laisse gérer pour la publication.
Commentaire de Cedric Favero [ 28/août/08 17:21 ]
Désolé mais encore quelques modifs à traduire.

Tjrs sur WWW , article 3 , on change notamment:

"Tout membre pourra devenir parrain via 2 types de parrainage :

- Par le parrainage classique:
Soit le membre remplit sur le site le formulaire de parrainage prévu à cet effet, dans lequel il précisera les adresses électroniques des internautes qu'il désire parrainer : ces internautes recevront alors un mail de leur part contenant un lien incluant un code identifiant le Parrain pointé vers la page d'accueil du Site.
Soit le membre transmet un mail, que $brandDto.brandName lui aura adressé, aux personnes de son choix, avec un lien incluant un code identifiant le Parrain pointé vers la page d'accueil du Site.

- Par le Widget Parrainage :
Le membre insère cet outil sur un service de communication au public en ligne dont il est l'éditeur."

puis

"Un parrain pourra parrainer au maximum 100 filleuls par type de parrainage."

et enfin:

"Un Parrain pourra parrainer au maximum 100 Filleuls par le biais du Widget Parrainage, en plus des 100 permis par le parrainage classique. "
Commentaire de Rocio Perez-Garcia [ 29/août/08 09:23 ]
Cédric, j'ai soumis à publication seulement les contents,(attention) aussi le FR et wwwFR.
Je ne mets pas ce Jira à publier sur IG car la structure est en working et sais pas laquelle tu vas laisser.

A publier:
/online_help/Help Articles/Folder Règlements/Folder Règlement du programme de Parrainage de $brandDto.brandName/ARTICLE 3 - MODALITES DE PARTICIPATION - Spanish (Spain) (245332)

/online_help/Help Articles/Folder Règlements/Folder Règlement du programme de Parrainage de $brandDto.brandName/ARTICLE 3 - MODALITES DE PARTICIPATION - WWW France (246195)

/online_help/Help Articles/Folder Règlements/Folder Règlement du programme de Parrainage de $brandDto.brandName/ARTICLE 3 - MODALITES DE PARTICIPATION - French (French) (245318)
Commentaire de Cedric Favero [ 29/août/08 09:35 ]
De toute façon quand je soumets , je soumets en meme temps la structure et tous les contenus associés..

Bon, par contre , il semblerait en fait que nombre de coupons possibles par parrainage classique soit de 200 dont au total 200+100 = 300 :-(

On tire çà au clair avant de refaire des modifs..
Commentaire de Cedric Favero [ 29/août/08 17:44 ]
publié sur cms1
V28 CTN-F




[APP-20921] [Fraudes] demande pour obtenir les fonctionnements de différents types de coupons Création: 20/juin/08 11:50  Mise à jour: 22/mars/10 11:58  Résolue: 17/févr./10 14:05

Etat: Fermé
Projet: Application PriceMinister
Composants: Coupons
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 65.0.0 (TX-M)

Type: Tâche Priorité: Majeur
Rapporteur: Cedric Favero Attribution: Clement Balay
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: PDF File Types_Coupons.pdf    
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***
Classif2: Self service Coupons

 Description   
Dans le but d'améliorer nos systèmes anti-fraudes, il nous faudrait les comportements exacts des types de coupons différents:

- STANDARD
- FIRST_COUPON
- FILLEUL
- PARRAIN
- LOTTERY
- LOTTERY_FIRST

En effet, il apparait qu'ils n'aient pas tous les memes verifications et niveau de sécurité quant aux droits d'utilisation.
On voudrait donc savoir pour chacun ce qu'il verifie exactement: IP , adresse de livraison , hash CB , etc...

Merci

 Commentaires   
Commentaire de Cedric Favero [ 24/juin/08 09:35 ]
Suis pas certain que celà doive passer par le pole TX.
Il ne s'agit pas d'un developpement mais uniquement d'une demande d'information détaillée.
Ne peut-on simplement nous répondre sur ce point?
Commentaire de Emeric Teil [ 25/août/08 15:53 ]
Je mets en PJ, un petit doc sur les différents types de coupons. Cependant, cela ne répond pas à la question en détail, pour cela, voir si un Dev a l'historique la dessus...
Commentaire de Arnaud Forgues [ 28/août/08 17:13 ]
Je renvoie chez Dispatcher-Dev pour un meilleur dispatch car je n'ai pas l'historique là-dessus.

A voir en COJIRA
Commentaire de Martin Sudmann [ 04/sept./08 18:21 ]
- STANDARD : on teste rien (le coupon est libre à être utilisé par la personne à qui il a été attribué
- FIRST_COUPON : on vérifie que l'utilisateur n'a encore jamais acheté (on essaye de trouver des articles / paniers avec ces données)
- FILLEUL : on vérifie que l'utilisateur n'a jamais encore acheté
- FILLEUL - PARRAIN : on vérifie que les deux ne soient pas identiques
- LOTTERY : attribué manuellement (à ma connaissance), donc pas de vérifs
- LOTTERY_FIRST : comme first coupon

sur l'écran d'un coupon il y a aussi tout un tas d'explications sur les règles métier du coupon.

Ca réponds à tes questions ?
Commentaire de Martin Sudmann [ 04/sept./08 18:22 ]
pour plus de détail il faudrait passer du temps le nez dans le code...
Commentaire de Cedric Favero [ 04/sept./08 18:33 ]
Merci pour tes réponses.
Malheureusement , c'est le détail des verifications exactes qu'il me faudrait.. Pour lever le doute sur un certain nombre d'idées reçues.
Pour ce qui est de l'écran coupon, il y a effectivement un certain nombre d'indications mais çà ne dit pas exactement ce que fait le type de coupon.

En particulier, j'aurais besoin de détails sur:

"FIRST_COUPON : on vérifie que l'utilisateur n'a encore jamais acheté (on essaye de trouver des articles / paniers avec ces données) "
=> est-ce qu'on ne vérifie que la carte (hash cb) ou est-ce qu'on a aussi un test sur l'IP ? ou autre chose (nom+prenom+adresse)?

"- FILLEUL : on vérifie que l'utilisateur n'a jamais encore acheté "
=> meme question: quelles données exactement sont testées? La carte uniquement?
Car si je regarde un coupon comme ALPACINO , on voit qu'il peut etre utilisé meme si on a déjà acheté.

"- FILLEUL - PARRAIN : on vérifie que les deux ne soient pas identiques"
??? Quel check est fait et à quel moment? Tu veux dire qu'on refuse le coupon si le filleul veut acheter à son parrain? Sur quelles bases?
A ma connaissance , la seule verif qui est faite par un coupon filleul , c'est s'il n'a pas déjà acheté chez nous mais pas s'il correspond en qqch à son parrain (d'où l'interet de rapports BI à posteriori pour matcher les IP , les mots de passe, les date de naissance, etc...)
Commentaire de Cedric Favero [ 04/sept./08 18:40 ]
Malheureusement, c'est bien ce qui est dans le code qui m'interesse, et pas juste ce qu'on pense qu'il fait.
Les rapports qu'on a pu faire sur les parrainages, l'utilisation des coupons, etc.. fait apparaitre un certain nombre de failles.. Et pour y remédier , il faut qu'on puisse partir sur des bases saines et donc etre certain de ce que font exactement tels ou tels coupons.

En gros , j'aurais besoin pour chaque type de savoir les checks effectués (hash CB , IP ? adresse ?, nom ? mot de passe ? ..)

Merci d'avance si ce n'est pas trop complexe.
Commentaire de Martin Sudmann [ 04/sept./08 18:43 ]
Il faut donc creuser le code ; le pôle TX s'en fera un plaisir.
Commentaire de Cedric Favero [ 04/sept./08 18:47 ]
La patate chaude :-)
Désolé les gars mais trop d'incertitudes , j'ai besoin de concret.

Merci à qui aura un peu de temps..
Commentaire de Emeric Teil [ 18/déc./08 14:58 ]
A regarder à l'occasion de l'étude technique pour le projet Self Service Coupons ?
Commentaire de Cedric Favero [ 18/déc./08 15:05 ]
Apres qques tests perso:

- FILLEUL - PARRAIN : ne fonctionne pas lorsque IP parrain et filleul sont identiques.
 Apparemment verification de l'adresse également (tous les champs adresse?)

Meme quand le coupon parrain est refusé à cause de çà , le coupon filleul n'est pas remis en cause.
Donc le mec qui s'auto-parraine bénéficie quand meme du coupon ALPACINO (meme si CORLEONE refusé).

Bcp de choses à revoir..
Commentaire de Emeric Teil [ 18/déc./08 15:06 ]
Oui, enfin la demande en question de regarder comment ça fonctionne pas de tout remettre en cause...
Commentaire de Cedric Favero [ 18/déc./08 15:09 ]
Chaque chose en son temps ;-)
Déjà si on me donne les clés de l'existant , çà levera un grand voile d'inconnu et de flou..
Merci.
Commentaire de Cedric Favero [ 19/déc./08 16:44 ]
En passant, exemple flagrant;
http://bo.priceminister.com/user_back?action=usersearch&email=bene.flouriot%40caramail.com&fuzzy=false&numberrows=200

Grace à une ECB non détectée la personne a pu faire 148 achats avec coupon!

Les coupons premier achat pourraient au moins vérifier l'adresse email en plus.
Commentaire de Clement Balay [ 19/févr./09 18:44 ]
J'ai crée un wiki qui explique un peu les coupons, ce WIKI n'est pas exhaustif. Dis moi si tu as encore des questions
Commentaire de Clement Balay [ 19/févr./09 18:45 ]
http://ruinart.lan:4080/pricewiki/Wiki.jsp?page=FonctionnementDesCoupons




[BIN-410] [Sales] : Seller commission title - vide Création: 15/févr./08 18:00  Mise à jour: 22/avr./08 15:55  Résolue: 28/févr./08 14:07

Etat: Fermé
Projet: Business Intelligence
Composants: Sales
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Benjamin Guerville Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Duplicate
a pour doublon BIN-411 Seller commission title - vide Fermé
Pays:
FRA - France

 Description   
Hello,

Je travaille sur un rapport faisant ressortir le type de commission :
Favoris/Benjamin/Rapport général VA CA

Parfois il n'y a pas de valeur pour cet objet alors qu'il devrait forcément en avoir un (ex : PRO:15%Fixe, PRO:8%Fixe, etc...)

Ca me pose des problèmes pour traiter les données correctement du coup.

Merci


 Commentaires   
Commentaire de Agathe Remy [ 28/févr./08 14:07 ]
Benjamin,

Après étude, il n'y a pas de bug au niveau BI : il existe bien des transactions ou des vendeurs qui ne sont associés à aucune classe de commission.

A priori, cela ne devrait plus exister aujourd'hui, puisque le volumes ont fortement diminué depuis août 2007 :
date_creation nb_transactions_capturees_sans_com
01/12/2007 1
01/06/2007 1
01/02/2007 1
01/10/2005 5
01/08/2004 1947
01/07/2004 3745
01/06/2004 3136
01/05/2004 2580
01/04/2004 110231
01/03/2004 139731
01/02/2004 133609
01/01/2004 142672
01/12/2003 138670
01/11/2003 129825
01/10/2003 120460
01/09/2003 105735
01/08/2003 86343
01/07/2003 80939
01/06/2003 78466
01/05/2003 86124
01/04/2003 86889
01/03/2003 86916
01/02/2003 78037
01/01/2003 77037
01/12/2002 73154
01/11/2002 68752
01/10/2002 57858
01/09/2002 48991
01/08/2002 41172
01/07/2002 35745
01/06/2002 31958
01/05/2002 32353
01/04/2002 26904
01/03/2002 27601
01/02/2002 21653
01/01/2002 22225
01/12/2001 14944
01/11/2001 11913
01/10/2001 8594
01/09/2001 5719
01/08/2001 4447
01/07/2001 2890
01/06/2001 2126
01/05/2001 1500
01/04/2001 887
01/03/2001 416
01/02/2001 65
01/01/2001 13

Ne pouvant pas inventer des données qui n'existent pas, je ne peux pas faire grand chose...

Une petite remarque : je te conseille d'utiliser la dimension Item/Item commission label plutôt que Seller account/Seller compensation/Seller commission title. En effet, la première correspond à la classe de commission appliquée lors de la transaction, alors que la seconde correspond à la classe de commission actuelle du vendeur.

Je reste à ta disposition si tu as des questions.

Agathe
Commentaire de Agathe Remy [ 28/févr./08 15:24 ]
Benjamin,

Dans le BackOffice, il y a possibilité d'affecter une classe de commission "Aucun" à un vendeur, ce qui a pour impact de passer la classe du vendeur à "NULL" dans la base.
Après étude, seul des vendeurs pros ont été affecté à cette valeur.

Pourrais-tu me dire dans quel cas vous réalisez ce genre d'opération?

Merci.

Agathe
Commentaire de Benjamin Guerville [ 28/févr./08 15:27 ]
ça ne me dit rien, tu as des exemple de vendeurs stp ?
Commentaire de Agathe Remy [ 28/févr./08 15:52 ]
user_account_id;login
64463;infowmg
3431570;directprice
4047547;Rafty
4141134;Lecritoire
4571647;ecolivres
4755098;PhoneCash
5324416;pass-tek
7741888;lapiere
10420139;CORTEX_REC
10674243;ggechevalier
11193618;bonprix8
11642863;micaba
12396758;vinyl74
12763933;CONTESDOR
Commentaire de Agathe Remy [ 18/avr./08 19:41 ]
Benjamin,

Des nouvelles sur la classe de commission "Aucun"?

Merci.
Agathe
Commentaire de Benjamin Guerville [ 21/avr./08 19:17 ]
Il s'agit essentiellement de comptes en -2, en vacances, inactifs, bloqués...

Souhaites-tu que je modifie le "Aucun" en "Particulier" par exemple ?
Commentaire de Agathe Remy [ 21/avr./08 19:45 ]
En effet, cela permettrait de résoudre les problèmes de reporting.
En revanche, je me demande s'il ne faut pas demander à l'équipe Développement de supprimer cette classe "Aucun". Qu'en penses-tu?

Agathe
Commentaire de Benjamin Guerville [ 22/avr./08 14:04 ]
ok je modifie les "aucun" et fait un Jira pour le supprimer.
merci
Commentaire de Agathe Remy [ 22/avr./08 15:55 ]
Suite à l'ouverture du JIRA APP, je ferme celui-ci.

Merci.
Agathe




[APP-22652] [PMV] Incohérence sur l'état du PMV de certains utilisateurs Création: 21/oct./08 13:58  Mise à jour: 07/janv./09 11:17  Résolue: 31/déc./08 15:12

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 31.0.3
Version(s) corrigée(s): 38.0.0 (TX-D Bis)

Type: Bogue Priorité: Majeur
Rapporteur: Arnaud Forgues Attribution: Arnaud Forgues
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** CHASSE ***

 Description   
Certains utilisateurs devraient avoir un PMV restreint et sont en Ouvert-intégral et vice-versa.

Incohérences à analyser et corriger

SQL> select count(*) from user_account where wlt_status_code = 30 and wallet_outgoing_amount = 0;

  COUNT(*)
----------
         5

Ecoulé : 00 :00 :13.49
SQL> select user_account_id from user_account where wlt_status_code = 30 and wallet_outgoing_amount = 0;

USER_ACCOUNT_ID
---------------
        8431904
       12464064
       15447010
       16910520
       17128378

Ecoulé : 00 :00 :02.55
SQL> select count(*) from user_account where wlt_status_code = 10 and wallet_outgoing_amount <> 0;

  COUNT(*)
----------
      3885


 Commentaires   
Commentaire de Arnaud Forgues [ 01/déc./08 19:21 ]
Concernant les 9 utilisateurs suivants, j'ai appliqué la méthode du "Bolcage/Déblocage" du PMV afin de repositionner l'état du PMV correctement ==> Ouvert-intégral :

SQL> select user_account_id, usr_visibility_code from user_account where wlt_status_code = 30 and wallet_outgoing_amount = 0;

USER_ACCOUNT_ID USR_VISIBILITY_CODE
--------------- -------------------
        6245372 -2
       12464064 1
       16454730 1
        4300037 -2
        8431904 1
       15517247 1
       15997195 -2
       17128378 1
       17371804 -2

La désynchro venait dans la plupart des cas d'un bug corrigé en TX-C mais qui avait laissé des cas non migrés à ce moment-là.

Pour le cas inverse (PMV Ouvert-intégral avec un montant sortant différent de 0), le cas peut en fait se produire lors d'un débit non FO en cours (ex.: Débit achat, ou Debit-PM ou encore avec l'opération systématique d'un compte compta), au final un seul cas se révèle illogique : voir le compte 598891 (nanette26)

select user_account_id, wallet_outgoing_amount
from user_account
where user_account_id IN (
            select u.user_account_id
            from user_account u
            where u.wlt_status_code = 10
            and u.wallet_outgoing_amount <> 0
            MINUS
            select u.user_account_id
            from user_account u
            where u.wlt_status_code = 10
            and u.wallet_outgoing_amount <> 0
            AND EXISTS(SELECT 1
                          FROM operation o
                          WHERE o.user_account_id = u.user_account_id
                          AND o.opr_type_code = 70
                          AND o.opr_status_code = 20)
            MINUS
            select u.user_account_id
            from user_account u
            where u.wlt_status_code = 10
            and u.wallet_outgoing_amount <> 0
            AND EXISTS(SELECT 1
                          FROM operation o
                          WHERE o.user_account_id = u.user_account_id
                          AND o.opr_type_code = 80
                          AND o.opr_status_code = 30)
            MINUS
            select u.user_account_id
            from user_account u
            where u.wlt_status_code = 10
            and u.wallet_outgoing_amount <> 0
            AND EXISTS(SELECT 1
                          FROM operation o
                          WHERE o.user_account_id = u.user_account_id
                          AND o.opr_type_code IN (60,90,100)
                          AND o.opr_status_code IN (20,30,70)
                          AND o.is_generated_by_system = 1
                          AND u.cmp_is_direct_payment = 1)
            )
Commentaire de Arnaud Forgues [ 01/déc./08 19:22 ]
Je laisse donc le SAV voir s'il y a quelque chose à faire de spécifique pour ce compte, car en regardant l'historique des opérations et les evenements du PMV, je ne comprend pas comment ce compte peut avoir un montant sortant du PMV différent de 0
Commentaire de Cedric Favero [ 15/déc./08 09:41 ]
Claire,

tu peux regarder le compte de nanette26 et retrouver à quelle opération pourrait correspondre les 4.42¿ sortants?
Et s'il n'y a rien de particulier avec cette opération.?

Merci.
Commentaire de Cedric Favero [ 15/déc./08 10:29 ]
a vu d'oeil on ne retrouve pas..

Une requete Bi nous donne les opérations suivantes pour un montant de 4.42. Il s'agit des debits PMV pour achats:

3269051 DEBIT_PURCHASE COMPLETED
4243470 DEBIT_PURCHASE COMPLETED
4737255 DEBIT_PURCHASE COMPLETED
7035566 DEBIT_PURCHASE COMPLETED
7823714 DEBIT_PURCHASE COMPLETED
8041473 DEBIT_PURCHASE COMPLETED

Voir si qqch de bizarre.
Commentaire de Claire Durand [ 15/déc./08 18:00 ]
j'ai vérifié toutes les opés de cédric et n'ai rien trouvé d'anormal
par contre en effectuant une recherche bo dans les différents types de débit, je ne retrouve pas cette ope
c claire ?
Commentaire de Arnaud Forgues [ 30/déc./08 12:15 ]
Les explications de Claire sont claires !

Mais j'ai cherché également de mon côté : en BDD ... et je n'ai rien trouvé qui explique cela.

Que souhaitez vous que l'on fasse avec ces 4¿ et quelques ?
- On peut remettre le montant sortant à 0, mais du coup cela sera au bénéfice de l'utilisateur.
- autres ...?
Commentaire de Cedric Favero [ 30/déc./08 13:45 ]
Agathe n'était pas venu te voir pour des pbs similaires?
Commentaire de Arnaud Forgues [ 30/déc./08 14:22 ]
Non je ne crois pas! Je te laisse réattribuer ce JIRA à Agathe si tu penses qu'elle a plus d'infos, sinon j'attend vos retours pour faire ce que l'on décide.

Merci
Commentaire de Cedric Favero [ 30/déc./08 18:02 ]
vu que ce n'est qu'un compte et qu'en plus il a fait des dizaines de milliers d'euros d'achat chez nous , je crois qu'on va faire au plus simple :-)
Remettons le montant sortant à 0 donc.
Commentaire de Arnaud Forgues [ 31/déc./08 15:12 ]
Ok !

Le script "V38_0_0_APP_22652_ALL_01_user_account_fix_wallet_outgoing_amount.sql" passera donc en INTEG puis en PROD pour la TX-D bis




[INF-162] Arrivée de Corinne GRONDIN Création: 23/sept./08 17:39  Mise à jour: 06/oct./08 10:48  Résolue: 06/oct./08 10:48

Etat: Fermé
Projet: Infrastructure
Composants: Arrivée/Départ
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Gafour Abdoul Attribution: Christophe Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word FICHE NOUVEL ARRIVANT.doc    

 Description   
Préparation de l'arrivée de Corinne GRONDIN

 Commentaires   
Commentaire de Gafour Abdoul [ 23/sept./08 17:57 ]
Salut Stéphane,

Concernant le PC de Corinne, je souhaiterais pour elle une machine avec plus de RAM (nous avons Paul et moi 2Go), le maximum de winXP est de 3Go je crois.

Pour les logiciels ils lui faudrait :
- la suite Adobe CS3 (ça ne posera pas problème si Paul et moi ne l'avons pas en même temps. on devrait pouvoir lui faire l'installation au pire)
- la suite office bien sûr

Pour le matériel :
- un PC Bi-écran
- une machine fraichement installée

A priori c'est tout.

Merci
Commentaire de Stéphane Eccli [ 03/oct./08 14:45 ]
comptes ok, reste Jira
Commentaire de Christophe Garcia [ 06/oct./08 10:48 ]
fait




[APP-22009] [Alerte - DEV USER - TX - (3)] - A user (n° 517503) without activation code trying to access to inventory activation - From url : /user?action=sellerprofile Création: 04/sept./08 18:18  Mise à jour: 10/oct./08 17:22  Résolue: 04/sept./08 18:28

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 26.0.2
Version(s) corrigée(s): 31.0.0 (TX-C)

Type: Bogue Priorité: Mineur
Rapporteur: Renaud Dierickx Attribution: Arnaud Forgues
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** CHASSE ***

 Commentaires   
Commentaire de Renaud Dierickx [ 04/sept./08 18:25 ]
Ces alertes se produisent pour les anciens utilisateurs n'ayant pas de code d'activation mais ayant déjà ouvert leur boutique...
Ce n'est donc pas un problème mais plutôt une alerte non cohérente.
J'ai corrigé ces alertes en les générant uniquement pour les utilisateurs n'ayant pas ouvert leur boutique ET n'ayant pas de code d'activation.

C'est donc corrigé !
Commentaire de Cédric Goldovsky [ 09/oct./08 11:37 ]
Par quel biais puis-je générer cette alerte ?

Par exemple pour le compte btapie/creditl je ne vois pas comment faire apparaitre cette erreur ?

Merci :-)
Commentaire de Espérance Galouo-Lece [ 10/oct./08 17:22 ]
 - Aucune alerte dans les logs




[APP-22972] [laredoute] désactiver l'auto Création: 06/nov./08 10:13  Mise à jour: 24/nov./08 16:37  Résolue: 24/nov./08 12:46

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 35.0.0 (CTN-H)
Version(s) corrigée(s): 35.0.0 (CTN-H)

Type: Amélioration Priorité: Majeur
Rapporteur: Swan Desportes Attribution: Damien Dorizy
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg     JPEG File screenshot-2.jpg     JPEG File screenshot-3.jpg    
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-22994 [laredoute] supprimer la page statiqu... Sub-improvement Fermé Jérémie Bennejean  
Pays:
FRA - France
Projets PM: *** CHASSE ***

 Description   
Il faut désactiver l'auto de laredoute avec les configs et vérifier que ça fonctionne bien.

 Commentaires   
Commentaire de Swan Desportes [ 06/nov./08 10:18 ]
Mail d'Emeric :

"Swan me disait la semaine dernière qu'on pouvait « simplement » désactiver cette partie. Je viens d'en discuter rapidement avec Alexandre et Clément et, à priori, il « suffirait » de :
- Couper la partie business via la property dédiée
- Supprimer la conf IG dédiée

Cela reste apparemment de la théorie car on n'a jamais essayé... mais l'implication Dev serait relativement limitée (dans l'absolu, on peut même imaginer que le premier aspect soit géré par l'Exploit et le second par le Param, même si en général, ce sont les Devs qui gèrent la config IG).

Ça, c'est pour l'option « brutale ». Après, si on souhaite gérer le travail en douceur, ça devrait être un peu plus laborieux... (et le mail du mec de LRO semble induire qu'il vaudrait mieux qu'on prenne des gants...)

Pour moi, deux options :
- On (qui ? Swan car CoB ou Bibi car Auto ?) fait une analyse plus poussée pour aider à la prise d'une décision
OU
- On teste directement en Integ pour voir ce qui se passe et en déduire, si besoin, les aspects à gérer plus en douceur....
"
Commentaire de Damien Dorizy [ 06/nov./08 18:17 ]
Ok pour la config, elle est supprimée pour la redoute :

cms1
default
/CONFIG

Voir pour l'espacement des onglets et si tout est ok dans mon compte, je laisse le Jira ouvert en attendant.
Commentaire de Ghislain Gridel [ 13/nov./08 14:39 ]
attention à bien nous tenir au courant sur le planning de désactivation car cela a un impact sur :
- le marketing
- le BI
- l'exploit.

Merci.
Commentaire de Damien Dorizy [ 13/nov./08 16:20 ]
Ghislain,

La désactivation de la Redoute aura lieu le 25 novembre, lors de la mise en production de la CTN-H.
Commentaire de Ghislain Gridel [ 13/nov./08 16:28 ]
c'est un peu tôt. peut-on décaler vers le 15/12, pour nous laisser le temps d'envoyer l'email ?
Commentaire de Swan Desportes [ 13/nov./08 16:31 ]
Désolé Ghislain mais nous avons fait une réu avec EMT il y a plus de deux semaines pour dire que la deadline était fin novembre.
Commentaire de Ghislain Gridel [ 13/nov./08 16:47 ]
ok. c'est un peu le rush du coup mais on va y arriver :-)
Commentaire de Aurélie Kwiatkowski [ 20/nov./08 16:19 ]
Une trace de l'auto sur la page Vendre, c'est normal?
L'onglet Vendre est un peu isolé, on ne peut pas le mettre avec les autres?
Commentaire de Aurélie Kwiatkowski [ 20/nov./08 16:21 ]
En fait, le bloc se trouve sur la page Tous les Produits.
Sur la page Vendre, il est toujours possible de vendre de l'Auto.
Commentaire de Damien Dorizy [ 20/nov./08 17:13 ]
En effet, c'est un contenu en trop. Le voilà supprimé :

cms1
/express/Article/Side Article/HP2007/Hp Left Auto - Via Michelin (261654)
/express/Article/Side Article/HP2007/Hp Left Auto - La Redoute (261653)
/express/Article/Side Article/HP2007/Hp Left Auto - Epik (261652)

Merci
Commentaire de Olga Costa [ 20/nov./08 18:06 ]
Damien il faut aussi faire sur CMS3
Commentaire de Damien Dorizy [ 20/nov./08 18:14 ]
Va falloir renommer express alors ;)

cms3
/express/Article/Side Article/HP2007/Hp Left Auto - Via Michelin (264009)
/express/Article/Side Article/HP2007/Hp Left Auto - La Redoute (264008)
/express/Article/Side Article/HP2007/Hp Left Auto - Epik (264007)

Merci
Commentaire de Emeric Teil [ 20/nov./08 19:11 ]
Pour l'isolement de l'onglet "Vendre", on s'est posé la question : Justin à tranché en estimant que cela pourrait au contraire augmenter la visibilité de ce bouton et que ce n'était donc pas un mal.
Commentaire de Cédric Goldovsky [ 21/nov./08 16:52 ]
J'ai vu un lien dans le footer, cf capture. Certainement rien de grave et une manip qui m'échappe mais je signale quand même.
Commentaire de Emeric Teil [ 21/nov./08 17:04 ]
Bien vu Cedric, merci. Damien ? :o)
Commentaire de Damien Dorizy [ 21/nov./08 17:19 ]
Bien ouéj.

C'était en dur dans le footer. C'est supprimé.
Commentaire de Christophe Garcia [ 24/nov./08 11:01 ]
Encore sur la page Vendre
Commentaire de Damien Dorizy [ 24/nov./08 12:44 ]
cms1 + cms3
/laredoute/Article/Vente/hp_vente

Merci Olga




[APP-23369] Rediriger BARGAIN vers quoi ? Création: 28/nov./08 11:28  Mise à jour: 08/janv./09 15:28  Résolue: 08/janv./09 12:10

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 38.0.0 (TX-D Bis)
Version(s) corrigée(s): 38.0.0 (TX-D Bis)

Type: Amélioration Priorité: Majeur
Rapporteur: Christophe Garcia Attribution: Arnaud Forgues
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Description   
Il reste une redirection vers de la NPC : celle de BARGAIN. Qu'en fait-on ?

# Rewrite /bargain with tracking (manage url with cgi and path mode)
# Compatibilité ancienne TG /bargain
RewriteCond %{QUERY_STRING} ".*t=.*" [OR]
RewriteCond %{QUERY_STRING} ".*tracking=.*"
RewriteRule ^/bargain /navigation/default/category/bargain [R,L,QSA,NE]

RewriteCond %{THE_REQUEST} "/bargain(.*)/t/(\S+)"
RewriteRule ^/bargain /navigation/default/category/bargain%1/t/%2 [R,L,NE]

RewriteCond %{THE_REQUEST} "/bargain(.*)/tracking/(\S+)"
RewriteRule ^/bargain /navigation/default/category/bargain%1/tracking/%2 [R,L,NE]

 Commentaires   
Commentaire de Marion Anfreville [ 22/déc./08 17:47 ]
Vu avec JEV : ce n'est pas de la NpC mais de la promo :
http://bo.priceminister.com/category_back?action=categorysearch&javascript_callback=&category_id=&ctg_status_code=&category_label=&category_alias=&ctg_type_code=&ctp_type_code=&ctg_parameter_value=bargain&category_soft_alias=&start_date=&date_search_type=0&end_date=&number_rows=100&x=0&y=0

La page affiche de vieilles TG (06/06/2006) => TG gérées par les commerciaux.
http://www.priceminister.com/navigation/default/category/bargain

Est-ce que quelqu'un sait par où on accède à cette page sur le site ?
Commentaire de Thierry Leforestier [ 22/déc./08 17:59 ]
Vraisemblablement uniquement par le biais de Google. Il faut voir avec les commerciaux si ils l'utilisent toujours, si ce n'est pas le cas, rediriger en 301 vers la home Price.
Commentaire de Thierry Leforestier [ 06/janv./09 09:53 ]
Pour le moment, nous n'avons pas trouvé a quoi pouvait servir cette page... étant donné qu'elle n'est pas référencée par Google, je vous laisse le soin de choisir vers ou elle sera redirigée.

Thierry
Commentaire de Christophe Garcia [ 08/janv./09 11:33 ]
Alors ce sera la Home
Commentaire de Christophe Garcia [ 08/janv./09 12:00 ]
Après vérification en PROD, il s'avère que cette page n'est plus appelée (sauf en interne pour générer une page statique).
Autant dire qu'au final, on fait sauter la redirection (et qu'on fera sauter la page statique)

Nicolas,
Merci de supprimer les lignes dans le rewrite.rules.fr
Commentaire de Arnaud Forgues [ 08/janv./09 12:10 ]
OK !

Règles supprimées du fichier rewrite.rules.fr

NB :
APP-23369 [V38] removed bargain rules

-------------- This line and the following will be ignored --------------

modified:
  source/etc/apache/rewrite.rules.fr

Committed revision 24944.
[forguesa@gobillard source]$ bzr tag --force V38_0_0
Created tag V38_0_0.




[IMP-3055] Le pro a importé son fichier ce matin pour les soldes > la pastille de réduction n'apparaît pas > maeva53 Création: 07/janv./09 12:30  Mise à jour: 30/oct./09 15:52  Résolue: 23/janv./09 11:46

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Bloquant
Rapporteur: Isabelle Weisbecker Attribution: Fotigui Tangara
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: maeva53
Séparateur: N/A
Type de traitement:
N/A

 Description   
Pourriez-vous vérifier que le pro ait bien mis 2 prix différents dans les 2 colonnes de prix. Il me dit que oui. Sinon pourriez-résoudre ce bug asap.

exemple de produit où il devrait y avoir une pastille de réduction
http://bo.priceminister.com/offer/buy/71476698/cpl73877986_ALL/Mini-Jupe-Carreaux-Ecossaise-Avec-Ceinture-Ultra-Sexy-Neuf-36-38-40-42-44-Sexy-Neuf-L-incontournable-De-La-Collection-Hiver-2008-2009-Expedie-En-24-48hrs.html



 Commentaires   
Commentaire de Fotigui Tangara [ 07/janv./09 13:56 ]
Peux-tu me faire une extraction de son stock dans sa totalité ?
Commentaire de Isabelle Weisbecker [ 07/janv./09 15:35 ]
le BI ne fonctionne pas depuis hier. si tu pouvais récupérer le fichier importé par le pro ce matin et le repasser ce serait cool.
Commentaire de Fotigui Tangara [ 07/janv./09 17:27 ]
le pro envoie une multitude de petits fichiers à chaque fois, c'est pas évident de toucher un max de fiches produits/annonces en même temps.
 soumettre de nouveau l'ensemble des fichiers qu'ils ont envoyé en la date d'aujourd'hui ?

J'ai modifié leur profil pour qu'il tienne compte de maj de fiches produits....
Commentaire de Fotigui Tangara [ 07/janv./09 17:28 ]
Je veux dire que le Pro doit soumettre de nouveau l'ensemble des fichiers qu'ils ont envoyé en la date d'aujourd'hui.
Commentaire de Isabelle Weisbecker [ 07/janv./09 18:14 ]
pas de bug pour la pastille de remise ? les prix etaient-ils identiques ou différents ?
Commentaire de Fotigui Tangara [ 08/janv./09 16:03 ]
J'ai testé quelques fichiers (les fichiers envoyés entre le 6 et 7/01/09), il y a bien les prix d'origine et les prix de vente qui sont différentes. Donc la pastille de remise devrait s'afficher avec le bon taux de réduction.

Mais si auparavant, certains fichiers ont été soumis sans "prix d'origine", la pastille ne s'affichera pas car le type de traitement appliqué ne permettait pas la mise à jour des fiches de produits. J'ai apporté une modification pour permettre la mise des fiches de produits, et cela depuis hier. C'est pour ces raisons que je préconisait qu'on fasse une extraction du stock du Pro, de filtrer les fiches de produits concernées, et de les traiter (les mettre à jour).....
 
Commentaire de Fotigui Tangara [ 14/janv./09 13:48 ]
Avez-vous pu avoir une extraction de stock pour ce partenaire ?
Commentaire de Fotigui Tangara [ 20/janv./09 11:32 ]
Cette demande est-elle toujours d'actualité ?
Commentaire de Fotigui Tangara [ 23/janv./09 11:44 ]
Je pense que je ferme cette demande pour laquelle je n'ai pas eu de retour.





[APP-23967] ES - Affiliation : Ajout d'un tag sur la page d'activation vendeur Création: 13/janv./09 15:41  Mise à jour: 16/févr./09 17:45  Résolue: 16/févr./09 17:45

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 40.0.1

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Charles Decaux Attribution: Rocio Perez-Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne
Projets PM: *** A PLANIFIER ***
WishList: Marketing
Classif FONC: webanalytics

 Description   
Hello,

on va lancer un programme d'affiliation qui rémunère les affiliés qui génèrent des premières mises en vente.
Il faut donc poser un tag sur la page d'activation vendeur.

Ce tag ne doit apparaître que si le last tracking est t=1438040 ou t=1416040

Voici le tag à poser :

<img src="http://tracking.publicidees.com/check.php?comid=107754&progid=902&uniqid=[NUMERO UNIQUE de l'ANNONCE]&price=&data=" width="0" height="0" border="0">

Plusieurs points aux quels il faut faire attention :
- si la page est sécurisée, remplacer http par https
- dans la variable uniqid, il faut mettre le numéro unique de l'annonce
- il ne faut pas conserver les crochets

Merci


 Commentaires   
Commentaire de Jérôme Viviès [ 19/janv./09 17:38 ]
Rocio, merci d'indiquer à Charles dans quel dump ça peut passer et quand ce sera en ligne, stp.
Commentaire de Rocio Perez-Garcia [ 22/janv./09 14:33 ]
Salut Charles,

le code tracking est paramétré en IG de façon qui reste 30 jours dans la cookie (comme en FR)

Concernant le point de variable uniqid, les dev me confirment que ce n'est pas possible dans la page Activation Vendeur (car le membre peut ouvrir sa boutique avec 1 ou 100 annonces).

Pour le tester il faut copier le code de activation boutique depuis le BO car les batch de mails ne tournent pas automatiquement en param et on perd Spot en chemin.

Si tu veux plus de précision ou qqch ne va pas suis à ta disposition.
Commentaire de Rocio Perez-Garcia [ 23/janv./09 09:46 ]
Charles,

Olga me confirme que le tag peut passer mercredi prochain.
Si c'est ok pour toi on le publie pour cette date.

Merci
Commentaire de Charles Decaux [ 23/janv./09 17:02 ]
Ok c'est bon pour moi, merci Rocio !!!!

Faut-il que je teste quelque part ?
Commentaire de Rocio Perez-Garcia [ 23/janv./09 18:10 ]
Oui, comme indiqué, tu peux tester en param2 ou avec spot. Mais pour ne pas perdre le tracking ou devoir relancer l'envoi des mails, tu dois recopier le code activation boutique de ton compte depuis le BO.
Alexandre Garnier et moi on a du tester comme ça et ça donne:

<img src="urlblocker://http://tracking.publicidees.com/check.php?comid=107754&progid=902&uniqid=&price=&data=" width="0" height="0" border="0">

A+
Commentaire de Charles Decaux [ 23/janv./09 18:16 ]
Ok merci Rocio.

Pourquoi y-a-t-il "urlblocker" au debut de l' URL ?
Commentaire de Alexandre Garnier [ 26/janv./09 09:51 ]
urlblocker est un moyen d'éviter de pourrir les données avec les tests en DEV et INTEG.
Ainsi, on écrit les tags mais les URL sont volontairement cassées pour ne pas envoyer les données aux partenaires.
Commentaire de Charles Decaux [ 03/févr./09 10:29 ]
Ok merci de ta réponse. Dans ce cas c'est bon pour moi, on peut passer en prod.
Commentaire de Rocio Perez-Garcia [ 04/févr./09 12:18 ]
Salut,
Charles m'a demandé hier si on pourrait mettre dans un tag de activation vendeur par « uniqid » la variable correspondante au identifiant vendeur.
Je ne le trouve pas et Olga m'a dit que seulement userid pourrait être compatible avec ce tag.
Vous pouvez me confirmer si existe la possibilité d'ajouter un identifiant ?

Merci
Commentaire de Charles Decaux [ 04/févr./09 12:56 ]
En fait, il faut juste regarder quelle variable a été passée sur le tag affiliation en France sur l'événement seller activation account et mettre exactement la même variable je pense. En effet, derrière ce tag, il y a des dépendances avec des rapports BI, c'est donc essentiel qu'on fasse exactement comme on a fait sur la France. Si le userid a été utilisé sur la France, alors mettons le userid.

Merci
Commentaire de Rocio Perez-Garcia [ 04/févr./09 16:58 ]
Sur France il a: $user.UserAccountId. J'ajoute ce paramètre.

A tester sur param2
merci
Commentaire de Charles Decaux [ 06/févr./09 09:52 ]
Rocio, peux-tu me rappeler l'URL de param2 ?
Merci !
Commentaire de Rocio Perez-Garcia [ 06/févr./09 11:57 ]
Bien sur:

http://www.param2.pm.dev/info/home

ou utiliser spot: http://bo.param2.pm.dev/spot_back
Commentaire de Rocio Perez-Garcia [ 09/févr./09 10:57 ]
En prod le 17/02.
Commentaire de Aurélie Kwiatkowski [ 16/févr./09 11:23 ]
Rocio,

J'ai testé en integ avec spot et je ne le trouve pas.
Il concerne quel évènement? Je ne le trouve ni avec first_advert, ni avec seller_account activation.
Commentaire de Aurélie Kwiatkowski [ 16/févr./09 17:45 ]
OK en integ

<!--@@@ Plubiidees t=1438040-1416040 Seller_account_activation : Event - Seller account activation -->
<img src="urlblocker://http://tracking.publicidees.com/check.php?comid=107754&progid=902&uniqid=16447193&price=&data=" width="0" height="0" border="0">




[IMP-3096] mettre le stock cosmétiques du pro à 0 > leadering Création: 15/janv./09 15:01  Mise à jour: 30/oct./09 15:53  Résolue: 16/janv./09 13:46

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Isabelle Weisbecker Attribution: Fotigui Tangara
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Advert_listing_by_login_parfum.csv    
Liens des demandes:
Duplicate
doublon de IMP-3093 demande de suppression format import ... Résolu
Pays:
FRA - France
Login: leadering
Séparateur: N/A
Type de traitement:
Mise à jour/création annonces avec mise à jour/création produits (écrasement)

 Description   
j'aurais voulu importer un fichier avec stock 0 pour supprimer ses annonces mais le lien des imports a déjà été supprimé. pouvez-vous juste supprimer les produits cosmétiques ? il y a plus de 10000 réf, difficile de les supprimer manuellement pour le pro.

 Commentaires   
Commentaire de Isabelle Weisbecker [ 15/janv./09 16:58 ]
comme discuté, en pièce jointe l'export BI des parfums. merci.
Commentaire de Fotigui Tangara [ 16/janv./09 11:00 ]
La suppression des annonces de type "COSMETIC" est en cours.
Suivra cette action, une suppression radicale de toutes les fiches produits ayant servi à la création des annonces de type "COSMETIC".

A suivre.
Commentaire de Cedric Favero [ 16/janv./09 11:05 ]
Super, merci.
Commentaire de Fotigui Tangara [ 16/janv./09 11:46 ]
Toutes les annonces type "COSMETIC" sont mortes !!!

Je m'attaque aux fiches produits maintenant :-)

Commentaire de Fotigui Tangara [ 16/janv./09 13:43 ]
Toutes les fiches produits ont été supprimées, n'hésitez pas à vérifier et me dire si tout est OK.

Demande traitée.

Commentaire de Aurélien Vergalli [ 16/janv./09 14:08 ]
Je confirme, c'est OK.
Merci.




[BIN-542] [CRM achat] : vérification d'un rapport perso Création: 08/janv./09 17:27  Mise à jour: 23/mars/09 13:52  Résolue: 14/janv./09 19:56

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Thomas Beylot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
hello

dans le cadre des prev 2009 je m'apprête à me servir d'un rapport comme étant la clé de voûte de tous mes chiffres. Sous mon perso il s'appelle "nombre d'acheteurs (dont nouveaux) par mois".
Pourriez vous me valider la bonne requête (c'est assez rapide, elle est très simple) pour que je sois sûr de bien faire les choses?

grand merci !

 Commentaires   
Commentaire de Agathe Remy [ 14/janv./09 19:56 ]
Bonsoir Thomas,

Ta requête semble juste : elle compte le nb d'acheteurs, dont nouveaux, ayant effectués au moins un panier autorisé par mois d'autorisation.
Mais comme tu n'indiques pas l'objectif de ce rapport, c'est un pur d'en dire plus.

Agathe
Commentaire de Agathe Remy [ 14/janv./09 20:04 ]
Attention, dans ton rapport tu inclus les négociations et les paniers Automobile...

Agathe
Commentaire de Thomas Beylot [ 15/janv./09 08:53 ]
ok je vais aller voir comment retirer ça
sinon en fait mon objectif est juste d'avoir un rapport pour lister le nb d'acheteurs et nouveaux par mois, histoire d'avoir des indicateurs pour faire mes prev et aussi me construire une sorte de scorecard fid.

voilà.
Commentaire de Agathe Remy [ 16/janv./09 19:37 ]
Pour information, la notion de 1er achat a été construite au tout début du BI. En validant les données UK et forts de notre expérience PriceMinistérienne, nous nous sommes aperçu que les règles de gestion ne sont pas tout à fait juste.
Après étude, je peux donc te garantir l'exactitude de l'information à 2% près.
Commentaire de Agathe Remy [ 16/janv./09 19:40 ]
Oups, j'ai cliqué trop vite:-(
Je continue :
Nous avons intégré à notre roadmap 2009 la correction de cette information pour la rendre tout à fait exacte et nous te tiendrons au courant de l'intégration de cette correction.

Agathe
Commentaire de Thomas Beylot [ 05/févr./09 10:56 ]
ok merci de l'info

me confirmes tu avant que je ne plonge dedans que je peux retirer les infos "auto" des rapports que je construis ?


thomas




[IMP-3133] Importer les prix d'origine = prix de vente > carthage51 Création: 22/janv./09 14:55  Mise à jour: 30/oct./09 15:52  Résolue: 22/janv./09 17:09

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Isabelle Weisbecker Attribution: Fotigui Tangara
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File Copie de Advert_listing_by_login.csv    
Pays:
FRA - France
Login: carthage51
Séparateur: Point-virgule (;)
Type de traitement:
Mise à jour/création annonces avec mise à jour/création produits

 Description   
Importer uniquement les prix, pas les quantités. le pro attend cet import pour pouvoir baisser ses prix et bénéficier de la pastille de réduction.

 Commentaires   
Commentaire de Fotigui Tangara [ 22/janv./09 15:07 ]
Pour que la pastille de réduction s'affiche, il faut le prix d'origine qui, comparé au prix de vente donne le pourcentage de réduction.
Dans le fichier en PJ, il manque le prix d'origine...
Commentaire de Isabelle Weisbecker [ 22/janv./09 15:36 ]
euh comment te dire, justement il n'y en a pas dans le fichier parcequ'il n'y en a pas sur le site. Je viens de faire un extract BI.

Peux-tu ajouter une colonne à l'endroit où il faut avec le même prix pour les 2 colonnes.
Commentaire de Fotigui Tangara [ 22/janv./09 15:59 ]
oui,
Je ferais la mise à jour des fiches de produits (car elles sont concernées par la maj du prix d'origine). Les prix d'origne seront égaux aux prix de vente, la pastille ne s'affichera pas, donc il va falloir passer un second fichier dont les prix de vente sont inférieurs au prix d'origine pour voir la pastille s'afficher...

On fait comme ça ?

Commentaire de Fotigui Tangara [ 22/janv./09 16:42 ]
Demande en cours de traitement.
Commentaire de Fotigui Tangara [ 22/janv./09 17:07 ]
Demande traitée.





[BIN-552] Accès au Rapport BO : "Purchase by purchase tracking" pour Swan Desportes Création: 22/janv./09 14:20  Mise à jour: 11/mars/09 09:45  Résolue: 05/févr./09 17:43

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Swan Desportes Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Hello

Je passe par JIRA pour vous demander accès un Rapport BO : "Purchase by purchase tracking"
J'utilise un compte technique commun.

Merci

 Commentaires   
Commentaire de Dalila Belkebir [ 22/janv./09 17:03 ]
Bonjour Swan,

Une refonte des accès est en cours et devrait être mise en production tout début de semaine prochaine.
Je prendrai en compte ta demande lors de cette refonte.

je te tiens au courant de la livraison des nouveaux droits.

Cordialement,
Dalila.
Commentaire de Dalila Belkebir [ 05/févr./09 17:43 ]
Bonjour Swan,

C'est livré en prod BI.

Merci de ton retour sur le JIRA pour fermeture de la demande.

Cdlt,
Dalila.
Commentaire de Agathe Remy [ 17/févr./09 11:42 ]
Bonjour Swan,

Peux-tu valider ce JIRA afin que nous puissions le clôturer?
Merci.
Agathe
Commentaire de Agathe Remy [ 05/mars/09 16:00 ]
Bonjour Swan,
3ème rappel!!!

S'il te plait, peux-tu valider ce JIRA afin que nous puissions le clôturer?
Merci.
Agathe
Commentaire de Swan Desportes [ 11/mars/09 09:36 ]
Merveilleux ! C'est bon
Désolé pour cette réponse tardive.

Merci




[BIN-551] [Sales] : extraction de stock collectorliv Création: 21/janv./09 14:20  Mise à jour: 28/janv./09 20:05  Résolue: 22/janv./09 16:42

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Anne Korchia Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File export de stock collectorliv 210109.rar    
Pays:
FRA - France

 Description   
extraction de stock collectorliv je n'arrive pas à le faire le client est très mécontent car n'a pas les données qu'il avait rentré au départ sur price à savoir auteur, éditeur année etc...
Pouvez vous faire quelque chose ?

 Commentaires   
Commentaire de Dalila Belkebir [ 22/janv./09 16:42 ]
Bonjour Anne,

Je me suis connectée au BI.
Dans Dossiers publics/ sales j'ai lancé le rapport "Advert listing by login " en mentionnant "collectorliv" comme login en invite.
Le fichier généré est joint au JIRA.

Si c'est OK pour toi, merci de me confirmer le JIRA pour clôture.

dalila.
Commentaire de Anne Korchia [ 22/janv./09 16:56 ]
je te remercie je pense que le fichier est correct je le renvoie au pro et on verra s'il a tout ce dont il a besoin
merci




[CAT-2502] Validation Welcome Process et Valorisation 1er achat Création: 28/janv./09 11:01  Mise à jour: 14/avr./10 09:14  Résolue: 14/avr./10 09:14

Etat: Résolu
Projet: Paramétrage - Non Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Pierre-Emmanuel Bianchi Attribution: Rocio Perez-Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne

 Description   
Rocío, tu m'avais fait savoir qu'il y avait quelques fautes dans l'un des Welcome Process... Je t'envois donc les liens, pour que tu puisses les checker. J'en profite également pour t'envoyer le lien du Mailing Valorisation 1er achat, au cas où.


Les WP :

http://www.priceminister.es/newletter/welcome_process/wp01/wp01.html
 
http://www.priceminister.es/newletter/welcome_process/wp02/wp02.html
 
http://www.priceminister.es/newletter/welcome_process/wp03/wp03.html
 
http://www.priceminister.es/newletter/welcome_process/wp04/wp04.html
 
Valorisation 1er achat :

http://www.priceminister.es/newletter/crm/2009-01-23-vpa/vpa.html


Pour info, les BAT nous serons envoyés en fin de semaine, pour une mise en production prévue pour début février.

Donc ça serait bien que tu puisses regarder ça aujourd'hui, afin que je puisse demander un dépannage aux graphistes s'il y a des choses à corriger.


Merci beaucoup.

 Commentaires   
Commentaire de Rocio Perez-Garcia [ 28/janv./09 11:16 ]
Avant de passer les corrections, j'ai une question: as tu demandé la permission au membre chuqui11 pour mettre ce témoignage à son nom? (on ne peut pas utiliser les pseudos sans permission...)
Ou pourquoi n'as pas tu pris celui de Juan qui est plus réaliste?
Commentaire de Pierre-Emmanuel Bianchi [ 28/janv./09 11:20 ]
Oui j'ai la permission de chuqui11 (c'est Charles jeje). Donc il n'y a pas de problème!!!
Commentaire de Rocio Perez-Garcia [ 28/janv./09 11:42 ]
Vale, tu me confirmes alors que dans le dernier Wp les témoignages sont validés par les utilisateurs?
Merci
Commentaire de Rocio Perez-Garcia [ 28/janv./09 12:07 ]
Salut Manu,

voici les corrections:

1er WP

Hola [[pseudo]],

¿Millones de productos nuevos y de segunda mano, vendidos tanto por particulares como por profesionales a precios de risa? ¡Eso es lo que te propone PriceMinister! Entonces ¡déjate seducir por el concepto, y descubre ya las ventajas de la compra-venta en Internet!

Ir a PriceMinister

-------------

2ème WP

Comprador o vendedor, PriceMinister quiere hacerte feliz.
¡Déjanos enseñarte nuestras ventajas!

-----

4ème WP

Alguien me dijo que:

Pas d'exclamations, nous ne l'utilisons presque pas, en dans ces phrases sont inutiles.

Además, los precios son muy económicos => es grass n'avons pas besoin de ¡!No se puede pedir más. ¡Estoy muy satisfecha!"

--Ce temoignage n'est ni espagnol ni latinoamericain...

"He llegado hace poco a España y me he dado cuenta de que PriceMinister era una buena opción para ganar dinero rápidamente. Puse mis anuncios y desde hace algunos meses, ¡ya he ganado más de 400 ¿! ¡Es genial,la verdad! Además, poner en venta es gratis. Muchas gracias a todo el equipo PriceMinister."


---

News ok
Commentaire de Rocio Perez-Garcia [ 29/janv./09 15:59 ]
Validation edito
Commentaire de Nerea Prieto [ 30/sept./09 16:50 ]
Bonjour,

Après tout ce qu'on s'est dit sur le mot "Listillo", je crois qu'il faudrait le remplacer, je propose aux espagnols de donner ses idées et après on vote la meilleur.

Voici les miennes:

- Astuto
- Avispado
- Espabilado
Commentaire de Pierre-Emmanuel Bianchi [ 02/oct./09 18:18 ]
Et "gorrón"?
Commentaire de Rocio Perez-Garcia [ 05/oct./09 11:41 ]
Gorrón es encore plus péjoratif que Listillo.

Je propose :
Ya has llegado al club de los que saben comprar
o comme dit Nerea,
 Bienvenido al club de los compradores astutos / espabilados / avispados (dans cet ordre de préférence)

Commentaire de Rocio Perez-Garcia [ 12/oct./09 17:25 ]
Il reste que Juan nos donne sa proposition et que Pierre-Emmanuel confirme le wording.
Commentaire de Juan Luis Fajardo [ 12/oct./09 17:35 ]
Ma proposition:

-----------------------------------------

1er WP

Hola [[pseudo]],

Priceminister te propone millones de productos nuevos y de segunda mano, vendidos tanto por particulares como por profesionales a precios de risa. ¡Déjate seducir por nuestro concepto, y descubre ya las ventajas de la compra-venta en Internet!

Ir a PriceMinister

-------------

2ème WP

Comprador o vendedor, PriceMinister quiere hacerte feliz.
¡Déjanos enseñarte nuestras ventajas!

-----

4ème WP

Temoignage:

"He llegado hace poco a España y me he dado cuenta de que PriceMinister era una buena opción para ganar dinero rápidamente. Puse mis anuncios y en pocos meses ya he ganado más de 400 euros ¡Es genial,la verdad! Además, poner en venta es gratis. Muchas gracias a todo el equipo PriceMinister."

-------

à la place de "listillo" o "gorrón", je préfère "comprador astuto"

Commentaire de Pierre-Emmanuel Bianchi [ 12/oct./09 17:57 ]
Je suis d'accord avec Juan Luis pour les WP 1, 2 et 4.

Concernant le mail Valorisation 1er achat, j'opterais pour un mix Nerea / Rocio. Ça donne:

Ya has llegado al club de los compradores astutos

On est tous d'accord sur le wording? Je peux demander à 1000Mercis de faire les modifs? (si ils ne peuvent pas le faire, je réserverai du temps graphiste).
Commentaire de Rocio Perez-Garcia [ 13/oct./09 11:49 ]
Ok pour moi. Dis moi si tu vas nos présenter les maquettes par le biais de ce jira ou je peux le fermer.

merci !
Commentaire de Pierre-Emmanuel Bianchi [ 13/oct./09 11:54 ]
Effectivement, je pense que ça passera par ce JIRA. Il est donc préférable de le laisser ouvert.

Merci.
Commentaire de Cantoni Carlos [ 23/oct./09 09:27 ]
des nouvelles par rapport a ce Jira?
j'ai reçu hier un mail avec l'objet

"eldiscoloco1, ¡Qué listillo eres! ¡Has descubierto el mejor Mercado de la Web!"
Commentaire de Rocio Perez-Garcia [ 18/déc./09 14:28 ]
Salut Pierre- Emmanuel, des nouvelles sur ce Jira ?
Une autre chose que je voulais te commenter : Plusieurs personnes avec une compte en PMES m'ont fait savoir qui ne reçoivent pas ni les news ni les CRM. Est-ce que tu peux te renseigner si la base de Mille mercis est à jour? ( en sachant que ils ont ouvert son compte à l'ouverture de PMES et qui font des achats c'est un peu bizarre).

Merci!!
Commentaire de Pierre-Emmanuel Bianchi [ 18/déc./09 14:57 ]
Salut Rocio :)

Pour les modifs éditos des mails automatisés, je m'en occuperai prochainement. Il faut que je réserve du temps graphiste, mais pour l'instant c'est un peu full.

Concernant ces personnes qui ne reçoivent pas les mails, je vais en parler à 1000mercis.

Merci,

P-E
Commentaire de Cantoni Carlos [ 05/mars/10 11:49 ]
des nouvelles par rapport a ce Jira?

j'ai reçu hier un mail aujourd'hui avec l'objet

"eldiscoloco1, ¡Qué listillo eres! ¡Has descubierto el mejor Mercado de la Web!"

de plus, il y a des liens qui ne marchent pas car nous avons fait des changements dans les filtres

exemple

cd nuevos a menos de 3¿ = Tu búsqueda no da ningún resultado.
Commentaire de Pierre-Emmanuel Bianchi [ 05/mars/10 11:54 ]
Bonjour à tous,

Étant donné le passage de 1000mercis à e-circle, tous les CRM automatisés vont -a priori- être momentanément interrompus. Cela nous permettra donc de faire toutes les modifs éditos et techniques (redirects) nécessaires.

Je vais réserver du temps graphiste, et vous tiens au courant. Je mettrai dans ce JIRA les maquettes des nouvelles versions dès qu'elles sont prêtes.

Merci,

P-E
Commentaire de Many Pes [ 08/mars/10 11:14 ]
Pour l'URL qui n'est pas redirigée:
CD nuevos por menos 3 euros:
On a ceci:
http://es.newsletter-priceminister.com/_c.aspx?i=12834&m=63&ue=21016811&r=46
Qui redirige en 302 vers:
http://www.priceminister.es/nav/Musica_CD/fp/NDe+1+a+3+%26euro%3B/ft/n?t=1474040
Or il y a une erreur dans l'URL: il y a un N devant le "De+1..." à la place du A (fp/ADe+1+...)

C'est pour ça que la redirection 301 ne fonctionne pas.

Si on teste cette URL: http://www.priceminister.es/nav/Musica_CD/fp/ADe+1+a+3+%26euro%3B/ft/n?t=1474040
La redirection 301 fonctionne bien.
Commentaire de Pierre-Emmanuel Bianchi [ 13/avr./10 18:39 ]
Bonjour à tous,

Je travaille actuellement sur le brief de refonte de ces mails (changement des redirects ne fonctionnant plus, correction édito, etc.). Il sera en PJ avant la fin de la semaine.

Mohamed effectuera quant à lui tous ces changements les 4 et 5 mai prochains.

Merci,

P-E
Commentaire de Rocio Perez-Garcia [ 14/avr./10 09:14 ]
Merci d'ouvrir une nouvelle demande pour la modification et corrections des nouveaux CRM.




[IMP-3338] exctract de stock : lhankor_mhy Création: 02/mars/09 10:40  Mise à jour: 30/oct./09 15:43  Résolue: 02/mars/09 11:07

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Anne Korchia Attribution: Frédéric Nahum
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: lhankor_mhy
Séparateur: N/A
Type de traitement:
N/A

 Description   
extraction de stock

 Commentaires   
Commentaire de Frédéric Nahum [ 02/mars/09 11:07 ]
Les imports ne font plus d'extraction de stock, ils ont fait directement par les commerciaux via l'outil BI




[BIN-560] [Marketing] : Vérification du rapport PMEV Last tracking Création: 23/févr./09 15:59  Mise à jour: 22/sept./09 10:29  Résolue: 22/sept./09 10:29

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Ghislain Gridel Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word BRIEF RAPPORT SUR LA VENTE.doc     Microsoft Word BRIEF RAPPORT SUR LA VENTEv2.doc     Microsoft Word DMR - Rapport PriceMinister - Advert followup by tracking and product family v1.1.docx    
Liens des demandes:
Similaire
similaire à BIN-420 [LRO] : Nombre de vendeurs/nouvelles ... Fermé
Pays:
FRA - France

 Description   
Bonjour Agathe,

nos tableaux de reporting évoluent et de nouveaux KPI s'ajoutent régulièrement. Nous aimerions suivre l'indicateur Première Mise en Vente (PMEV) en last tracking par canal d'acquisition. Pour l'instant le critère 30 jours n'existe pas appremment.
Peux-tu vérifier que les informations contenues dans ce rapport sont les bonnes stp ? Merci !

Favori > Ghislain > page 2 > New Seller par tracking pas à 30 jours

A ta dispo pour toute question.

Ghislain

 Commentaires   
Commentaire de Agathe Remy [ 23/févr./09 19:40 ]
Bonjour Ghislain,

D'après ce que j'ai compris des précédents échanges de mails, cet indicateur doit servir à des arbitrages budgétaires.
Je pense donc qu'il est important de passer par un process BI de qualification de l'information fournie pour être sûr que ce soit la bonne, c'est à dire ne pas se contenter d'une simple "validation d'un rapport perso", mais par le développement d'un rapport public.
En effet, la validation du rapport perso ne peut avoir qu'une valeur ponctuelle au moment de la-dite validation puisque vous pouvez modifiez ultérieurement le rapport et induire de potentielles erreurs.
D'autre part, comme nous n'avons pas la maîtrise de ces rapports, nous n'y reportons pas les évolutions du site, induisant également de potentielles erreurs.
Je pense également qu'il serait intéressant d'impliquer Thomas afin que, même si vous gérez des budgets et partenaires distincts, vous parliez le même langage et ayez conscience des éventuelles différences de stratégies induites par vos objectifs.
Nous te proposons donc de développer un rapport BI qui sera livré dans l'arborescence "Dossiers publics" en respectant le process spécifications, développement, validation et livraison.
Ce développement a d'ailleurs été priorisé par Odile pour début Q2 si vous nous livrez un brief avant fin mars.

Pour info, à ma connaissance, il est tout à fait possible aujourd'hui de compter les premières mises en vente effectuées dans les 30 jours après le dépôt du coockie par le partenaire.

A ta dispo pour en discuter.

Agathe
Commentaire de Ghislain Gridel [ 27/févr./09 17:30 ]
Merci Agathe. Bien noté. Je vous laisse développer ce rapport.
Tant mieux si le last tracking 30 jours existe.
De quel éléments supplémentaires as-tu besoin ?
Commentaire de Ghislain Gridel [ 04/mars/09 09:22 ]
le brief est ci-joint. A ta dispo pour toute question.
Commentaire de Ghislain Gridel [ 06/mars/09 12:30 ]
Une modification dans le brief, si possible il faudrait rajouter aussi la possibilité de pouvoir avoir ces chiffres sur le trafic spontané
Commentaire de Ghislain Gridel [ 06/mars/09 16:30 ]
par spontané j'entends "le reste du monde"
Commentaire de Agathe Remy [ 14/mai/09 17:00 ]
Voici le rapport initial qu'il s'agit de faire évoluer.

Agathe
Commentaire de Dalila Belkebir [ 29/mai/09 14:45 ]
Bonjour Ghislain,

Comme validé, je joins les spécifications que j'ai rédigées pour la demande.
Les développements peuvent débuter.

Je te tiens au courant de la mise à disposition des rapports spécifiés.

Cdlt,
Dalila.
Commentaire de Dalila Belkebir [ 12/juin/09 17:32 ]
Bonjour,

Dans le répertoire ADVERT, les anciens rapports Advert followup by tracking et Advert followup by tracking and product type qui n'étaient pas utilisés ont été supprimés et refondus en 2 nouveaux rapports :

¿ Monthly advert followup by tracking and product family
        Ce rapport a pour objectif le suivi de la mise en vente et du nombre de vendeurs dont nouveaux, par mois d'activité, groupe de tracking et famille de produit.

¿ Daily advert followup by tracking and product family
       Ce rapport a pour objectif le suivi de la mise en vente et du nombre de vendeurs dont nouveaux, par jour d'activité, groupe de tracking et famille de produit.

Ces modifications ont eu lieu sur les plateformes France, UK & ESPAGNE.

Merci de vos retours.

Cdlt,
Dalila.
Commentaire de Ghislain Gridel [ 15/juin/09 18:55 ]
merci !
Commentaire de Agathe Remy [ 17/août/09 15:39 ]
Bonjour Thomas,

S'il te plait, peux-tu également valider ces rapports ?

Merci.

Agathe
Commentaire de Thomas Beylot [ 17/août/09 15:41 ]
hello

validation itou

tu peux closer le jira :)
Commentaire de Agathe Remy [ 17/août/09 15:42 ]
Merci!
Commentaire de Ghislain Gridel [ 18/août/09 10:49 ]
hello,
les modifications demandées à la réunion de présentation du rapport n'ont pas été faites. ce jira ne peut donc pas être clôturé.
Commentaire de Dalila Belkebir [ 18/sept./09 10:39 ]
Bonjour Ghislain,

Les éléments remontés lors de la réunion de présentation sont des éléments d'évolution du rapport qui a été développé conformément aux spécifications validées.

Je te propose donc de clôturer ce JIRA et de m'en créer un autre en y mentionnant les évolutions remontées lors de la réunion.
Voici les retours que j'ai notés :
- supprimer la colonne New seller count, redondante avec First advert count
- supprimer la section sur la date
-supprimer la rupture sur le tracking name pour l'afficher sur toutes les lignes de la colonne

Est-ce bien cela ?

Ces modifications interviennent essentiellement au niveau de la mise en forme afin de vous faciliter le retraitement des données dans excel.
Aussi, si tu me fais ce JIRA assez rapidement je pourrais le traiter afin de clôturer le sujet.

Cdlt,
dalila.
Commentaire de Ghislain Gridel [ 21/sept./09 12:16 ]
http://pricejira.lan/browse/BIN-628
Commentaire de Dalila Belkebir [ 22/sept./09 10:29 ]
Ghislain,

merci de ton retour.
Je clôture la demande.

les évolutions demandées seront donc traitées dans le JIRA
http://pricejira.lan/browse/BIN-628

cdlt,
dalila.




[APP-24658] Configuration Page Dédiée Jeux concours films HUMAINS Création: 17/mars/09 10:06  Mise à jour: 02/avr./09 10:01  Résolue: 26/mars/09 10:29

Etat: Fermé
Projet: Application PriceMinister
Composants: Infoglue, Promo
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 43.0.3

Type: Tâche Priorité: Majeur
Rapporteur: Charlotte Fachan Attribution: Carole Boucheny
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-24806 Impossible d'utiliser le scroller de ... Sub-bug Fermé Carole Boucheny  
APP-24808 Interrogation sur le wording Sub-bug Fermé Carole Boucheny  
APP-24810 Liens background accéssible depuis le... Sub-bug Fermé Carole Boucheny  
Pays:
FRA - France
Projets PM: *** RESERVE ***
Classif FONC: comarket

 Commentaires   
Commentaire de Charlotte Fachan [ 17/mars/09 10:25 ]
Il faudrait prevoir la mise en ligne d'une page dédiée Infoglue faisant la promotion de la sortie du Film Humains du 1/04/09 au 30/04/09.

Quand doit-on vous fournir les éléments pour une mise en prod le 01/04 ?

Merci

Charlotte
Commentaire de Marion Anfreville [ 18/mars/09 11:51 ]
Nous avons besoin des éléments vendredi soir (20/03) pour qu'on puisse paramétrer/tester S13 et mettre en prod S14 (Dump 31/03 pour activation le 01/04).
Commentaire de Charlotte Fachan [ 20/mars/09 18:32 ]
Comme convenu, les éléments relatifs à la page dédiée HUMAINS ont été déposées dans Infoglue.

http://bo.test-fr.pm.dev/info/no/op/humains

Nicolas doit encore faire quelques modifs lundi matin en arrivant.

A votre dispo pour en parler

Très bon week end

Charlotte
Commentaire de Charlotte Fachan [ 23/mars/09 10:06 ]
Tout est ok pour les éléments transmis. les dernières modifs ont été faites.

merci

Charlotte
Commentaire de Carole Boucheny [ 24/mars/09 12:00 ]
Fait sur cms1.

promotions/Direct Article/Opérations Marketing/humains

Testable ici : http://bo.ref-fr.pm.dev/info/no/op/humains.


Pouvez-vous valider ??

Merci
Commentaire de Charlotte Fachan [ 24/mars/09 12:10 ]
ok pour moi !

merci

Charlotte
Commentaire de Carole Boucheny [ 24/mars/09 16:03 ]
Olga,

Peux-tu mettre une version et valider ?

Merci
Commentaire de Olga Costa [ 25/mars/09 10:53 ]
J'ai testé la page, ok pour moi

Par contre une question comment accède-t-on à cette page ? (une banner promos ? un lien ?)

Merci
Commentaire de Charlotte Fachan [ 25/mars/09 11:45 ]
Par le biais de bannières promo mises en place via ID REGIE.

Charlotte




[BIN-568] [BACK-OFFICE] optimisation requete evenements USER Création: 10/mars/09 16:30  Mise à jour: 06/avr./09 19:56  Résolue: 19/mars/09 10:40

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Cedric Favero Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
J'ai une requete qui apparemment fait planter la base :-(

Malheureusement je suis amené à en avoir besoin souvent et celà meriterait donc optimisation.

Il s'agit d'une requete recherchant tous les comptes ayant eu un evenement Login pour une IP donnée.

A votre dispo pour plus d'informations.






 Commentaires   
Commentaire de Agathe Remy [ 10/mars/09 16:37 ]
Cédric,

S'il te plait, peux-tu préciser le nom et l'emplacement du rapport afin que nous récupérions la requête?

Merci.
Agathe
Commentaire de Cedric Favero [ 10/mars/09 16:42 ]
C'est chez moi , je partage pas mes requetes perso :-)
Commentaire de Cedric Favero [ 10/mars/09 16:43 ]
C'est "Recherche_connexions_par_IP" dans Dossiers Publics/ France / BO Working
Commentaire de Julien Girardet [ 19/mars/09 10:40 ]
Bonjour Cedric,

Les dernieres optimisations livrées dans le cadre du projet BI Abonnement, améliorent les performances de ton rapport "Recherche_connexions_par_IP" . Il s'execute en 5/6 min.

Peux tu valider de ton coté ?

Merci

Julien.
Commentaire de Cedric Favero [ 19/mars/09 13:01 ]
Ca marche du tonnerre!
Merci.




[BIN-592] [Sales] : Ajout des objets "libération accès adresse email" et "libération accès du numéro de téléphone acheteur" Création: 11/juin/09 11:23  Mise à jour: 03/juil./09 10:00

Etat: Bloqué
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Gaël Seguillon Attribution: Agathe Remy
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
GBR - Royaume Uni, FRA - France, ESP - Espagne

 Description   
Ce rapport consisterait à donner un reporting mensuel des comptes ayant les droits libérés sur l'accès au téléphone et/ou à l'email de leurs acheteurs.
Aujourd'hui cette donnée ne figure pas le profil User.
Les données nécessaires du rapport sont le pseudo, le type de compte (pro/part), le gestionnaire de compte, l'info sur 2 colonnes droits libérés email (O/N) droit libérés téléphone (O/N).
Ce rapport ne doit lister que les comptes dont au moins un de ces deux droits est débloqués
merci
Gaël

 Commentaires   
Commentaire de Gaël Seguillon [ 17/juin/09 11:23 ]
ajouter cette donnée dans univers Item
Commentaire de Agathe Remy [ 02/juil./09 19:56 ]
Bonsoir Gaël,

Lors du développement, nous nous sommes aperçu que ces informations étaient mal alimentées dans le BI.
Nous sommes donc dans l'incapacité de te les mettre à disposition sans faire évoluer l'alimentation.

Nous te proposons donc d'ajouter cette évolution dans le prochain projet qui fera évoluer l'alimentation d'un compte utilisateur.
Nous reviendrons vers toi lorsque nous aurons des infos sur un tel projet.

Agathe
Commentaire de Agathe Remy [ 02/juil./09 19:59 ]
Nous ne pouvons donc pas mettre en place de rapport de suivi.
En revanche, si ton besoin est ponctuel et urgent, nous pouvons te proposer de réaliser un étude ponctuelle.

A ta dispo si tu as des questions

Agathe
Commentaire de Gaël Seguillon [ 03/juil./09 10:00 ]
Bonjour
je serai preneur de la liste des pros sur FR ES UK
qui ont l'accés aux emailset/ou ou tél des acheteurs
par avance merci




[APP-25517] [Extension de garantie] suppression de trois tables plus utilisées Création: 08/juin/09 11:47  Mise à jour: 26/janv./10 14:33  Résolue: 25/janv./10 13:51

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 49.0.0 (TX-H)
Version(s) corrigée(s): 60.0.0 (TX-L)

Type: Tâche Priorité: Mineur
Rapporteur: Clement Balay Attribution: Marc-Antoine Decreton
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** CHASSE ***

 Description   
Dans ce projet, nous avons crée trois nouvelles tables dans un nouveau schéma (config_1) et laissé les trois tables existantes pour ne pas gêner les devs.
en version N+2, nous pouvons supprimer ces tables vu que toutes les branches sont mises à jour.

Il s'agissait des tables:
COMMISSION, COMMISSION_RULE et CMR_TYPE_CODE dans le schéma user_1.

 Commentaires   
Commentaire de Clement Balay [ 23/oct./09 12:20 ]
CAJ2009Q4TX
Commentaire de Clement Balay [ 23/oct./09 12:21 ]
Jira corrigé en TX-K, mais version pas dans jira encore
Commentaire de Christophe Garcia [ 23/oct./09 15:12 ]
MDPLVC
Commentaire de Clement Balay [ 23/oct./09 15:19 ]
En fait il me faudrait la version TX-K svp
Commentaire de Christophe Garcia [ 23/oct./09 16:55 ]
Tu l'as.
Commentaire de Clement Balay [ 23/oct./09 16:59 ]
Merci
Commentaire de Clement Balay [ 17/nov./09 10:17 ]
On le fera passer en TX-Q pour plus de sureté
Commentaire de Christophe Garcia [ 17/nov./09 10:32 ]
Tu veux que j'ajoute des lettres à l'alphabet ?
Commentaire de Christophe Garcia [ 17/nov./09 10:32 ]
MDPLVC
Commentaire de Clement Balay [ 17/nov./09 10:35 ]
Tant qu'à faire, si tu pouvais monter jusqu'à Z,
pour la suite on prendra peut-être les lettres de l'alphabet grec
Commentaire de Arnaud Forgues [ 25/janv./10 13:51 ]
En fait, ce nettoyage a été fait en TX-L :
- en DEV : OK
- en INTEG : OK (mais il y a eu une copie de la PROD sur l'integ ensuite ....)
- en PROD : NOK --> géré par PPE / BI




[BIN-585] [Marketing Acquisition] : Rapport commission autorisée Création: 26/mai/09 14:51  Mise à jour: 28/janv./10 12:28  Résolue: 07/oct./09 18:00

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Ghislain Gridel Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word DMR - Rapport Daily item followup by tracking and product family v1.0.docx     Microsoft Excel Maquette.xls    
Pays:
FRA - France

 Description   
Hello,

dans le cadre du suivi des campagnes de liens sponsorisés, nous aurions besoin d'un rapport qui nous donne la commission autorisée à 30 jours, par groupe et par code de tracking. Est-ce possible ?

Merci.

Ghislain

 Commentaires   
Commentaire de Agathe Remy [ 26/mai/09 19:33 ]
Bien sûr que c'est possible!

Pour étudier ta demande, il faudrait nous faire un brief avec :
- le contexte du besoin
- l'objectif principal du rapport
- le mode d'utilisation (ponctuel, quotidien, hebdo, mensuel, etc...)
- les critères de sélection (période de mois, groupe de tracking, etc...)
- une maquette

Merci.

Agathe
Commentaire de Ghislain Gridel [ 29/mai/09 15:06 ]
hello,

Contexte
Nous avons décidé de ne pas envoyer d'informations capturées à notre agence de liens sponsorisés car trop coûteux en temps technique. Nous leur enverrons uniquement les informations capturées.
Par conséquent, nous envisageons de modifier la rémunération de l'agence. Leur rémunération actuelle est composée d'une partie fixe qui se déclenche par palier en fonction du budget investi; et composée d'une partie variable qui se déclenche à partir de palier de ROI calculé sur la commission capturée.
Comme ils ne disposeront d'aucune information capturée pour optimiser les campagnes, nous ne pouvons pas les rémunérer sur la commission capturée en ce qui concerne la 2ème partie de la rémunération. Nous souhaiterions donc les rémunérer sur la commission autorisée.
Hors aujourd'hui nous ne disposons pas d'informations relative à la commission autorisée.

Objectif
Suivre les le taux de perte entre le va / commission autorisée et le va / commission capturée par campagne et par sous-catégorie (ex CD). L'idée est de voir si cette perte augmente/baisse afin de mieux comprendre pourquoi le résultat net des campagnes pourrait augmenter/baisser. On entend par résultat net la différence entre les coûts (CPC payé à Google + rémunération Keyade) et la commission PM.

Utilisation
Quotidienne et mensuelle

critère de sélection
période de mois, période de jour (l'un et l'autre à choisir en fonction du besoin), groupe de tracking, code de tracking, catégorie, sous-catégorie.
Le VA autorisé doit être le même que dans le rapport Purchase tracking by month (avec frais de port, avec CBV) et la commission doit inclure le CBV.
A voir si on crée une colonne CBV à part ?

Maquette
Mois | groupe de tracking | code de tracking | catégorie | sous-catégorie | VA Autorisé | VA capturé | Commission autorisée | Commission capturée

A votre dispo
Ghislain
Commentaire de Julien Girardet [ 21/sept./09 11:49 ]
Bonjour Ghislain,

Voici la maquette du rapport fait à partir de ton brief.

Quelques explications :

Critères de sélection :
- periode de jour d'autorisation
- un ou plusieurs groupe de tracking
- une ou plusieurs famille de produit

Le rapport est par jour, groupe de tracking, tracking, famille de produit et type de produit
Il n'y a pas de rupture et de section, donc pas de sous totaux

Le rapport est en tracking 30 jours

Le GMS (autorisé et capturé) inclut les frais de port et les garanties

Les commissions sont détaillées par : article, frais de port, garanties

Enfin, il y a aura un écart sur le VA autorisé avec les tableaux de bords MKT (Monthly purchase overview (30 days tracking)/ Weekly purchase overview (30 days tracking))
Ces rapports se base sur Purchase alors que ce nouveau rapport se base sur l'univers Item (car on veut la commission autorisée)
Or il y a deux causes d'écart avec les rapports se basant sur Purchase :

Panier en confirmation Denied :
Ce sont des paniers autorisés mais dont les articles ont été supprimés par batch (autorisation de paiement refusée, panier vidé par le systeme)
Ainsi le VA autorise calculé niveau ITEM ne prend pas en compte ces articles supprimés.
  
Le recalcul des frais de ports mutualisés :
Ce sont les paniers autorisés contenant plusieurs articles chez un-même vendeur dont au moins un article a été annulé.
Ainsi le VA autorisé calculé niveau ITEM prend en compte le recalcul en fonction du nombre d'articles annulés chez un même vendeur.

(=> voir JIRA BIN 584 [Keyade] : Etude évolution autorisé/capturé)


Es tu dispo demain pour en discuter ?

Julien.

Commentaire de Julien Girardet [ 23/sept./09 11:15 ]
Bonjour Ghislain,

Ci joint la specification du rapport.

Peux tu la valider ?
Suite à ta validation, nous commencerons le developpement du rapport.

Merci

Julien.
Commentaire de Ghislain Gridel [ 23/sept./09 11:54 ]
ok pour moi. Merci.
Commentaire de Dalila Belkebir [ 07/oct./09 18:00 ]
Bonjour Ghislain,

Nous venons de livrer le rapport après validation.

Il est dans le répertoire PUBLIC / ITEM
 Daily item follow up by purchase tracking and product family

Merci de ta validation pour clôture du JIRA.

Cdlt,
Dalila.
Commentaire de Dalila Belkebir [ 28/janv./10 12:28 ]
Odile,

Comme vu en point MKT BI du 18/01, cette demande est OK pour vous.

Cdlt,
Dalila.




[BIN-619] Ajout dimension correspondant au RawListCaption Création: 27/juil./09 17:51  Mise à jour: 31/juil./09 12:34  Résolue: 31/juil./09 12:34

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Habib-Sylvain Gourguet Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Pour une meilleure gestion des articles revendus sur "retourpm", nous aurions besoin du RawListCaption dans "Product", pour les univers "ITEM" et "ADVERT".

 Commentaires   
Commentaire de Agathe Remy [ 31/juil./09 12:34 ]
Désolée, mais le RawListCaption n'est pas un champ base de données, mais une information fournie par le moteur de recherche:-(
Nous sommes donc aujourd'hui incapable de fournir cette info dans BI.

Agathe




[BIN-600] [Compta] : Génération de l'historique du rapport "buyer refund" sur la France - 2007 - 2008 - 2009 Création: 30/juin/09 11:31  Mise à jour: 01/oct./09 11:38  Résolue: 17/juil./09 16:39

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Bloquant
Rapporteur: Claudie Dufresne Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Agathe, Dalila,

Comme vu ensemble, les rapports "buyer refund by claim closing month" pour les années 2007,2008 et 2009 sont trop volumineux pour être édités, année par année, en un seul fichier.
Nous avons besoin d'éditer ces fichiers tous les mois le jour où les opérations du mois précédent sont stabilisées.

Est-il donc possible pour vous de prévoir une édition programmée de ces fichiers (un fichier par année) tous les mois (le jour de stabilisation des opérations de M-1)et dès la stabilisation des opérations du mois de juin ?

merci par avance pour votre aide
claudie


 Commentaires   
Commentaire de Julien Girardet [ 07/juil./09 16:46 ]
Claudie,

Aujourd'hui les chiffres sont stabilisés, j'ai donc généré les données "buyer refund"
Je vais pouvoir créer les rapports d'historique.

Sinon, Il existe 2 rapports sur les remboursements acheteurs :
- Buyer refund by claim closing month : Ce rapport a pour objectif de fournir le détail de toutes les opérations de remboursement acheteur par article pour une période de clôture de réclamation.
- Buyer refund without claim by completion month : Ce rapport a pour objectif de fournir le détail de toutes les opérations de remboursement acheteur pour les articles sans réclamation pour une période de finalisation des opérations.

As tu besoin de l'historique du second rapport "Buyer refund without claim by completion month " pour la réconciliation ?
Puisque qu'il ne traite pas des réclamations ...

Julien.
Commentaire de Claudie Dufresne [ 07/juil./09 18:32 ]
Julien

non effectivement, il nous faut uniquement le rapport "buyer refund by claim closing month"
merci à toi
claudie
Commentaire de Julien Girardet [ 17/juil./09 16:39 ]
Bonjour Claudie,

Tu trouveras l'historique du rapport « Buyer refund by claim closing month » pour 2007, 2008 et 2009 dans le répertoire : T:\BI\00 - Projets\2009-07 Historique Buyer Refund

2007 - Buyer refund by claim closing month.xlsx
2008 - Buyer refund by claim closing month.xlsx
2009 - Buyer refund by claim closing month.xlsx

L'historique a été généré le jour de la stabilisation des chiffres du mois de Juillet, c'est-à-dire le 07/07/2009

A ta disposition si tu as des questions.

 
Julien.
Commentaire de Dalila Belkebir [ 30/sept./09 13:44 ]
Bonjour Claudie,

Peut-on clôturer ce JIRA STP ?

Merci.

cdlt,
Dalila.
Commentaire de Claudie Dufresne [ 01/oct./09 11:36 ]
bonjour Dalila,
oui vous pouvez le cloturer.
nous aurons à nouveau besoin de faire une édition de ces rapports d'ici la fin d'année, mais j'ouvrirai un nouveau JIRA
merci à toi
claudie
Commentaire de Dalila Belkebir [ 01/oct./09 11:38 ]
Merci de ton retour Claudie.

OK pour le JIRA de fin d'année !

Cdlt,
Dalila.




[BIN-602] [Sales] : rapport France - Advert and product count by family and product type fichier toujours en erreur Création: 04/juil./09 17:22  Mise à jour: 02/nov./09 11:02  Résolue: 17/juil./09 11:36

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Gaël Seguillon Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
 Bonjour
malgré la planification avec invite par type de produits
je n'arrive pas à sortir le rapport France - Advert and product count by family and product type sur CD et Livres les rapports restent en erreur ce rapport nous permet de suivre l'évolution du nbre d'annonces actives et du taux de couverture de la base de données
Gaël

 Commentaires   
Commentaire de Agathe Remy [ 15/juil./09 17:53 ]
Bonjour Gaël,

S'il te plait, peux-tu préciser dans quel dossier se trouve ce rapport?

Merci.
Agathe
Commentaire de Agathe Remy [ 15/juil./09 19:26 ]
Bonsoir Gaël,

Pour Livre, tu essaie d'extraire plus de 4.2 millions de FP, ce qui est beaucoup trop pour BI. Essaie encore d'affiner ton découpage : par exemple en sélectionnant une période de création de la fiche produit ou en découpant par qualité d'annonce (Neuf, Comme neuf, Etat correct, etc..)
De même, pour les CD, ton extraction dépasse les 800 000 FP...

D'autre part, je te conseille fortement d'éviter de programmer tes planifications à la même heure le même jour : en effet, elles vont se neutraliser en se ralentissant les unes les autres. Il vaut mieux échelonner les planifications dans le temps.

Agathe
Commentaire de Gaël Seguillon [ 16/juil./09 09:07 ]
ok bien compris
merci de ton aide
Gaël
Commentaire de Agathe Remy [ 10/sept./09 15:07 ]
Bonjour Gaël,

Est-ce que je peux clôturer ce JIRA?

Merci.

Agathe
Commentaire de Dalila Belkebir [ 30/sept./09 13:47 ]
Bonjour Gaël,

Est-ce que je peux clôturer ce JIRA?


Cdlt,
Dalila.




[BIN-618] [BackOffice] : Ajout "User Remark" dans USER ACCOUNT Création: 24/juil./09 14:30  Mise à jour: 10/mai/10 14:12  Résolue: 25/sept./09 15:58

Etat: Fermé
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Habib-Sylvain Gourguet Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Besoin de pouvoir effectuer des recherches sur le contenu du champ "Remarque" dans le compte d'un utilisateur.

Ajouter "User Remark" dans "User account", dans l'univers "USER ACCOUNT".

Merci d'avance.

 Commentaires   
Commentaire de Agathe Remy [ 31/juil./09 12:48 ]
Bonjour,

Nous pouvons créer une dimension permettant d'afficher le champ "Remarque" dans un rapport.
En revanche, utiliser cette dimension comme condition pour effectuer des recherches ne sera pas une utilisation normale du BI et donc risque d'avoir des performances très médiocres.
Est-ce que tu veux quand même que nous ajoutions cette information?

Merci de ton retour,
Agathe
Commentaire de Habib-Sylvain Gourguet [ 31/juil./09 13:36 ]
Oui, avoir cette info serait tout de même utile.

On pourra obtenir un résultat proche de celui recherché en affinant la requête.

Merci.
Commentaire de Dalila Belkebir [ 25/sept./09 15:58 ]
Bonjour Habib,

La demande a été livrée, peux-tu stp nous la valider pour clôture du JIRA ?

Merci.

Cdlt,
dalila.




[META-TACHE] Modification des tracking sites-under + tracking e-mails questions (APP-26706)

[APP-26957] Modification rapports clubic Création: 23/oct./09 10:26  Mise à jour: 31/mai/10 10:30  Résolue: 28/mai/10 14:10

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 69.0.1.0 (MeV 4G Info - Lot 2)

Type: Sous-tâche Priorité: Mineur
Rapporteur: Ghislain Gridel Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File clubic appel à facture mensuel.JPG     File rapport hebdo clubic.bmp     File rapport hebdo clubic.bmp     JPEG File rapport hebdo clubic.JPG    
Pays:
FRA - France
Projets PM: *** A PLANIFIER ***

 Commentaires   
Commentaire de Ghislain Gridel [ 23/oct./09 10:27 ]
Bonjour,
clubic a accepté le changement de rémunération. Le contrat est en cours de rédaction.


Peut-on modifier le rapport automatique svp ?
PriceMinister : Partner - Weekly revenue by tracking group
PriceMinister : Clubic - Appel à facture mensuel

Il faut modifier :
- le VA capturé en commission capturée
- La rémunération de 8% du VA capturée à 57.5% de la commission capturée

Le nombre de paniers ne change pas.

Merci !

Ghisalin
Commentaire de Ghislain Gridel [ 23/oct./09 10:38 ]
indications détaillées ci-joint
Commentaire de Dalila Belkebir [ 27/oct./09 11:45 ]
Bonjour,

La modification doit être apportée pour quand ? pour un appel à facture sur les chiffres d'octobre ? de Novembre ?
Pourrions nous avoir l'extrait du contrat qui parle de la rémunération afin de bien vérifier les calculs à implémenter ?

Merci de votre retour.

Cdlt,
Dalila.
Commentaire de Mathilde Caby [ 27/oct./09 12:04 ]
Bonjour Dalila,

C'est Mathieu qui s'occupe de Clubic, il ne revient que vendredi.

Je peux déjà te dire que ces nouveaux rapports seront nécessaires pour la facturation de novembre (pas d'octobre)

Bonne journée
Mathilde
Commentaire de Mathieu Richomme [ 30/oct./09 12:48 ]
57.5% de la commission hors taxe hors frais de port
cf les 2 schémas de Ghislain

le contrat est en cours de validation par le service juridique du partenaire
mais il ne servira pas à grand chose pour notre rapport BI : nous n'indiquons pas dans le contrat s'il s'agit de la commission hors frais de port ou avec frais de port

le modèle change à partir du 1er novembre, le partenaire doit continuer à recevoir les rapports hebdo avec la nouvelle rem pour avoir une visibilité sur la transfo

merci
Mathieu
Commentaire de Mathieu Richomme [ 09/nov./09 11:14 ]
les rapports envoyés aujourd'hui au partenaire n'ont pas été modifiés
le nouveau modèle de rémunération est pourtant déjà en place
le partenaire est donc dans l'incapacité de faire des optimisations
quand pourrons-nous avoir les nouveaux rapports ?

d'avance merci
Commentaire de Dalila Belkebir [ 09/nov./09 11:50 ]
Mathieu,

désolée, j'ai mal lu et j'ai cru comprendre que tu en avais besoin pr le reporting mensuel.

Les rapports sont prêts, je les valide ce jour et te les mets à dispo en production.

Cdlt,
Dalila.
Commentaire de Christophe Garcia [ 27/mai/10 14:19 ]
MDPLVC




[EXP-4998] Impossible de me connecter au BO de PROD Espagne Création: 02/nov./09 15:47  Mise à jour: 04/janv./10 17:52  Résolue: 04/janv./10 17:52

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Ariane Baldinger Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne

 Description   
Ca fait plus d'une semaine que je ne peux plus me connecter au BO de Prod Espagne sous FF.


 Commentaires   
Commentaire de Gaël Seguillon [ 03/déc./09 14:03 ]
Bonjour
on un souci persistant pour se connecter au BO espagne, il faut revalider à plusieurs reprises pseudo et mot de passe, ce qui est gênant pour moi est que je ne peux plus ouvrir directement les liens des rapports BI, je suis obligé de faire du copier coller dans le navigateur pour avoir accès aux pages des liens pas forcément optimal en terme de fonctionnement.
merci
Gaël
Commentaire de Laura Yeo [ 03/déc./09 14:54 ]

Problème bien connu au SAV ES, il faut presque quotidiennement valider 3/4 fois le log+mdp avant de pouvoir se connecter au BO ES.

Navigateur utilisé: Firefox version 3.0.10 (des fois que...)

Laura.
Commentaire de Stéphanie BOILLON [ 03/déc./09 15:38 ]
Problème également de mon coté, qui m'empêche parfois de traiter directement sur le BO ES.

Parfois besoin d'une 10aine de tentatives ...
De plus, il m'est impossible de cocher la case pour enregistrer le mot de passe, je dois donc le retaper à toutes les tentatives.

Stephanie.
Commentaire de Jérémie Bennejean [ 21/déc./09 15:29 ]
Hello,

J'ai vu une erreur de syntaxe dans la conf jboss d'un des serveurs sur lequel la probabilité de se connecter est forte.
Après le redémarrage de demain matin, les changements seront effectifs.
Je pense que cela devrait corriger le problème.

Merci.
Jérémie.
Commentaire de Laura Yeo [ 21/déc./09 16:01 ]
Super, on espère tous que ça va résoudre le pb.

Merci!
Commentaire de Ariane Baldinger [ 22/déc./09 10:11 ]
ça marche de mon côté
Merci
Commentaire de Jérémie Bennejean [ 23/déc./09 16:41 ]
C'est bon pour tout le monde ?
Commentaire de Laura Yeo [ 23/déc./09 16:59 ]
Perfect côté BO, gracias.




[BIN-635] Historique des rapports "buyer refund by claim closing month" et "buyer refund without claim by completion month" Création: 16/nov./09 18:10  Mise à jour: 28/janv./10 12:19  Résolue: 10/déc./09 10:03

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Claudie Dufresne Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Dalila, Julien,

Comme vu ensemble, nous aurions besoin d'une édition de l'historique de ces rapports sur la FRANCE :
- une première fois le jour de la stabilisation des chiffres de novembre (donc vers le 8-10 déc) ==> pour nous permettre de finaliser quelques analyses et estimations avant la fin de l'année, notamment sur les claims antérieures à 2008.
- une deuxième fois le jour de la stabilisation des chiffres de décembre (donc vers le 8-10 janv 2010) ==> ceci pour avoir des rapports mis à jour à la date du 31/12/2009.

il faudrait éditer l'historique en trois parties :
- une première édition allant de janvier 2001 à décembre 2007
- une édition pour uniquement 2008
- une édition pour uniquement 2009

merci à vous
claudie




 Commentaires   
Commentaire de Julien Girardet [ 10/déc./09 10:03 ]
Bonjour Claudie,

Tu trouveras l'historique du buyer refund ici : T:\BI\02 - Historiques de données\2009-12 Historique Buyer Refund.

A ta dispo pour plus d'infos.

Julien.
Commentaire de Dalila Belkebir [ 28/janv./10 11:12 ]
Bonjour Claudie,

Peux-tu nous valider le JIRA pour clôture STP ?

Merci.

Cdlt,
Dalila.
Commentaire de Claudie Dufresne [ 28/janv./10 12:06 ]
Dalila, Julien,
tout est ok, vous pouvez cloturer le JIRA
merci à vous
claudie




[APP-27258] lien "Modifier Mon avis" mort pour certains avis Création: 12/nov./09 12:05  Mise à jour: 28/janv./10 17:54  Résolue: 17/nov./09 17:07

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 61.0.0 (CTN-O)

Type: Bogue Priorité: Majeur
Rapporteur: M'hand Hadjoudj Attribution: Alexandre Garnier
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
FRA - France
Site: Prod
Projets PM: *** CHASSE ***
Navigateur: Tous

 Description   
Le lien "Modifier Mon avis" ne fonction pas ni en prod ni en integ dans la page "Mes Avis"
essayer avec le login "zodiak91"
voir screenshot-1

(Depuis le projet avis lot 2)

 Commentaires   
Commentaire de Fabrice Feugas [ 12/nov./09 12:14 ]
J'arrive pas à reproduire !!!
Commentaire de Alexandre Garnier [ 12/nov./09 12:27 ]
Problème JS (visible aussi sous Firefox) :

<script type="text/javascript">
var review-7 = new PM.Review(PM.Review.Page.MY_REVIEWS, "70321557", "-7", "5", "SAMSUNG PLAYER ADDICT OMNIA", "Trés bon téléphone !!!");
PM.Util.addEvent("link_show_form-7", "click", PM.Review.displayForm.bindObj({review: review-7, scroll: false}));
</script>

--> "missing ; before statement"

Surement un problème avec les avis qui possèdent des avis avec des ID négatifs !!!???
Commentaire de Alexandre Garnier [ 12/nov./09 12:35 ]
Ça sent le problème de migration des opinions qui a généré des ids négatifs

select review_id from review where review_id < 0;
-7
-6
-4
-3
-2
-1

--> faudrait peut-être corriger les ids de ces avis.
Commentaire de Alexandre Garnier [ 13/nov./09 12:34 ]
Pour les DBA :
 * est-ce faisable de corriger des id négatifs avec un script ? (en gros les FK sont vérifiées au commit ou à l'update ?) (en tout cas en dev, j'ai essayé et voir plus bas)
 * est-ce possible de savoir toutes les FK qui pointent vers les review.review_id ?

En DEV j'ai fait :

SQL> select review_id from review where review_id < 0;
 REVIEW_ID
----------
        -7
        -6
        -5
        -4
        -3
        -2
        -1
7 rows selected.
Elapsed: 00:00:00.01

SQL> update review set review_id = review_seq.nextval where review_id = -1;
1 row updated.
Elapsed: 00:00:35.90

SQL> commit;
Commit complete.
Elapsed: 00:00:00.00

SQL> select review_id from rvw_event where review_id < 0;
 REVIEW_ID
----------
        -7
        -6
        -5
        -4
        -3
        -2
        -1
7 rows selected.
Elapsed: 00:00:00.02

SQL> select review_id from review where review_id < 0;
 REVIEW_ID
----------
        -7
        -6
        -5
        -4
        -3
        -2
6 rows selected.
Elapsed: 00:00:00.00
Commentaire de M'hand Hadjoudj [ 13/nov./09 14:39 ]
donc, si j'ai bien compris les review_id négative font que le lien ne marche pas c'est ça. (entitiyid !!!)
Commentaire de Ayoub Benseghir [ 13/nov./09 14:44 ]
 * est-ce faisable de corriger des id négatifs avec un script ? (en gros les FK sont vérifiées au commit ou à l'update ?) (en tout cas en dev, j'ai essayé et voir plus bas)
Oui, c'est faisable par script (d'ailleurs c'est surement le seul moyen).
 * est-ce possible de savoir toutes les FK qui pointent vers les review.review_id ?
SQL> select table_name from all_constraints where r_constraint_name='PK_REVIEW';
TABLE_NAME
------------------------------
OBSERVATION
USR_MESSAGE
FEEDBACK
REVIEW_GAME
Commentaire de Alexandre Garnier [ 16/nov./09 10:01 ]
@M'hand : les review_id négatifs font que le JS des formulaires ne fonctionne pas
Commentaire de Alexandre Garnier [ 17/nov./09 16:59 ]
Script : APP-27258_CTN-N_ALL_correction_review_id_negatifs.sql pour CTN-O

Garder les logs pour fournir au BI pour qu'ils fassent la même migration de leur côté.

Sinon au passage, je sais pas pourquoi mais il manque la FK des événements avis ...




[APP-27758] les numéros de facture (paiement sur porte-monnaie) sont bloqués à #100.000 Création: 23/déc./09 11:27  Mise à jour: 26/janv./10 14:32  Résolue: 29/déc./09 16:02

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 59.0.2
Version(s) corrigée(s): 60.0.0 (TX-L)

Type: Bogue Priorité: Majeur
Rapporteur: Steven Harel Attribution: Arnaud Forgues
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
FRA - France
Site: Prod
Projets PM: *** CHASSE ***

 Description   
lors d'un transfert des ventes sur le porte-monnaie, un numéro de facture est généré.

du type Waaaammxxxxxx

avec aaaa : année
mm : mois
xxx : numéro incrémental

les numéros de facture semblent aujourd'hui être bloqués au numéro 100.000
-> tous les transferts après la facture W20091299999 ont le même numéro : W200912100000 !

 Commentaires   
Commentaire de Steven Harel [ 23/déc./09 12:06 ]
même chose sur les derniers numéros de facture de novembre
Commentaire de Emeric Teil [ 23/déc./09 14:25 ]
Pas mal ça... :o)

Question pour être sur : ce numéro est bien remis à 0 au début de chaque échéance de compensation ? si tel est le cas, cela signifie qu'on a eu plus de 100 000 compensations sur les dates concernées ?
Commentaire de Steven Harel [ 23/déc./09 15:09 ]
le numéro est remis à jour au début de chaque mois. vu le nombre de transferts de ventes, les factures avec les numéros au dessus de 100.000 commencent en ce moment dès le 10 du mois :(
Commentaire de Steven Harel [ 23/déc./09 15:37 ]
d'après le bi, 234.325 compensations sur le pmv en novembre, 219.153 du 01 au 22 décembre.
Commentaire de Arnaud Forgues [ 29/déc./09 14:35 ]
En effet, en réalité c'est depuis septembre 2008 que le problème existe !

Num. Max Total Groupe facture
------------------------------------------------
     58151 58207 W200807
     62814 62880 W200808
    100000 100992 W200809
    100000 163945 W200810
    100000 186524 W200811
    100000 208958 W200812
    100000 211578 W200901
    100000 200460 W200902
    100000 202775 W200903
    100000 192251 W200904
    100000 189765 W200905
    100000 239073 W200906
    100000 181903 W200907
    100000 191188 W200908
    100000 226929 W200909
    100000 240479 W200910
    100000 238357 W200911
    100000 250151 W200912

Comme vu avec Steven, on va donc à présent limiter à 7 chiffres max au lieu de 5 (comme actuellement).
--> Ainsi pour chaque mois de l'année, on aura un numéro de facture qui ira de "0000001" à "9999999". Pour les factures suivantes, ca marchera mais le format d'affichage sera donc sur plus de 7 chiffres, c'est tout.
--> On se donne donc un peu de marge en passant à 7 chiffres plutot que seulement 6, car on est déjà à ~250 000 factures par mois, on peut donc imaginer/espérer atteindre le million d'ici quelques années

NB : j'ai vérifié avec Philippe, et ces numéros de factures ne sont pas utilisés par la compta. Cependant si on voulait être au carré fiscalement, on devrait avoir un numéro de facture qui incrémente tout au long de l'année et qui se réinitialise 1 seule fois par an et non chaque mois ... mais bon rien d'urgent néanmoins (vu avec PFA)
Commentaire de Arnaud Forgues [ 29/déc./09 16:02 ]
Ok ! Commité sur la branche dev_tx.

CAJ2009Q4TX




[BIN-638] EXTRACT CIBLE pour OP mailing postal Colissimo/PM (2) Création: 30/nov./09 13:58  Mise à jour: 04/janv./10 15:25  Résolue: 01/déc./09 14:21

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Charlotte Fachan Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Extract final_CelligiblesOPSept09.xlsx    
Pays:
FRA - France

 Description   
Dalila,

comme vu ensemble, ci joint le second extract correspondant à la cible 1 de l'OP Colissimo_Pm de décembre
POur rappel :
Cible 1 : clients ayant déjà utilisé le service (op sept / oct) => soit une estimation de 3 000 clients
Cible 2 : Clients vendeurs PriceMinister (Vendeurs particuliers hors cobrandé ayant réalisé au moins 2 ventes, pas de blacklist, pas de fraudeur, pas de claims, avec adresse postale de paiement en France) avec adresses nettoyées (dédoublonnées du fichier du mailing de sept/ oct et des clients ayant bénéficié de l'offre) => soit une estimation d'environ 25 000 clients
Cible 3 : Client base colissimo.fr (dédoublonnés du fichier du mailing de septembre / octobre et des clients ayant bénéficié de l'offre des 3¿)=> soit une estimation d'environ 22 000 clients

Il faudrait pouvoir ressortir les critères d'informations suivants correspondant :
ID user
Adresse
CP
Ville

Je dois l'envoyer ce soir à PN DATA.
DItes moi si c'est jouable pour vous aujourd'hui ou pas !

A votre dispo pour plus d'infos
Merci
Charlotte

 Commentaires   
Commentaire de Dalila Belkebir [ 30/nov./09 14:16 ]
Charlotte,

On va essayer de faire le maximum pour te sortir ce dont tuas besoin.
Toutefois, comme vu ensemble ce matin, nous devons rédiger une requête et la relancer plusieurs fois pour avoir les infos sur l'ensemble de ton échantillon.

Julien s'en occupe.

cdlt,
Dalila.
Commentaire de Julien Girardet [ 30/nov./09 18:13 ]
Désolé Charlotte, mais je ne pourrais pas te fournir les données ce soir.
Je vais essayer pour demain midi.
Pour info, retrouver les users a partir d'un mail c'est tres long...

Julien.
Commentaire de Charlotte Fachan [ 30/nov./09 18:28 ]
ok merci
Commentaire de Julien Girardet [ 01/déc./09 14:21 ]
Charlotte,

L'extract est dispo ici : T:\BI\01 - Demandes ponctuelles\2009-12 Extract OP colissimo JIRA BIN-636

Le fichier est : Extract OP colissimo_2.xlsx

Julien.
Commentaire de Charlotte Fachan [ 01/déc./09 17:09 ]
Super
merci Julien pour ta récativité.
Charlotte
Commentaire de Charlotte Fachan [ 01/déc./09 17:11 ]
Juste une question : pourquoi y a t- il plus de ligne dans le nouvel extract que dans le fichier initial transmis (environ 30 de plus) ?

Merci
Charlotte
Commentaire de Julien Girardet [ 01/déc./09 17:15 ]
Car pour un mail, tu peux trouver plusieurs comptes.
Commentaire de Charlotte Fachan [ 01/déc./09 17:32 ]
ok merci




[APP-27452] Bug sur le TAG Zanox sur un nombre non significatif de panier Création: 30/nov./09 14:27  Mise à jour: 08/janv./10 17:01  Résolue: 04/janv./10 17:48

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation
Affecte la/les version(s): 57.0.2
Version(s) corrigée(s): 59.0.3

Type: Bogue Priorité: Critique
Rapporteur: Mathilde Caby Attribution: Olga Costa
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: *** A PLANIFIER ***

 Description   
Bonjour,

La technique de Zanox nous remonte des BUG sur certain panier:
ID est remplacé dans ces bug par: $purchase.AffiliationRef

Cela corresponds à 25 paniers depuis le mois de novembre.

Voici les dates auxquels ils sont remontés:
27.11.2009 21:13:04
27.11.2009 13:15:52
23.11.2009 21:27:38
23.11.2009 15:03:43
23.11.2009 13:37:04
22.11.2009 21:44:42
21.11.2009 09:53:11
20.11.2009 17:44:58
19.11.2009 19:10:03
16.11.2009 20:47:26
16.11.2009 20:24:26
15.11.2009 14:30:21
15.11.2009 13:16:14
14.11.2009 16:13:40
14.11.2009 12:51:35
12.11.2009 23:00:57
11.11.2009 16:27:57
10.11.2009 17:53:25
09.11.2009 23:16:36
07.11.2009 23:40:36
06.11.2009 11:32:43
04.11.2009 20:22:35
04.11.2009 13:51:39
03.11.2009 19:21:49
01.11.2009 14:43:17


Aucune donné du panier ne remonte donc.
Je reste à votre disposition pour en discuter
Merci
Mathilde


 Commentaires   
Commentaire de Olga Costa [ 03/déc./09 15:59 ]
Nous avons dans le tag OrderID=[[$!purchase.AffiliationRef]] et on recouper le numéro de la commande. Et le numéro commande et obligatoire si je ne me trompe pas, donc cette variable doit toujours avoir une valeur. je vois pas pk sur certain panier elle n'est pas interpréter
Commentaire de Jérôme Viviès [ 08/déc./09 15:57 ]
Salut les Devs !

Une idée là-dessus ?

On met un "!" devant le "$" ? ou autre ?

Sinon je ferme le JIRA...
Commentaire de Alexandre Garnier [ 08/déc./09 16:24 ]
Le '!' se met après le '$' ce qui semble déjà la cas pour certains tags mais pas d'autres.

Sinon, d'après le code, il n'est pas possible que cette variable soit vide : elle vaut au moins "_" --> c'est donc que le panier n'existe pas dans le contexte

--> vérifier que sur toutes les pages/événements où ce tag est censé apparaitre, le panier est bien dans le contexte

Théoriquement, il y a du y avoir des logs Velocity qui devraient être remontés en parallèle --> devrait permettre de remonter aux cas où ces tags erronés on été affichés

Au passage : panier --> pôle TX aussi qui sont surement plus au courant des variables disponibles dans le panier !

Une dernière remarque : c'est la même que APP-3790, APP-26707 : un problème d'affichage du tag dans des conditions où le contexte est insuffisant ou l'absence d'un contexte suffisant dans les circonstances où le tag s'affiche.
Commentaire de Olga Costa [ 08/déc./09 16:42 ]
Le '!' est déjà en place pour ce tag ces tag a pour évènement buy et/ou first buy et je pense que les variables sont bien présentes sur les pages concernées pas ces évènements puisque nous n'avons pas de pb avec d'autres tags (qui utilise mêmes événement et mêmes variables) ???
Commentaire de Alexandre Garnier [ 08/déc./09 16:44 ]
APP-26707 : il y a eu le même problème avec effiliation !
Commentaire de Olga Costa [ 08/déc./09 17:07 ]
Mathilde, est ce que le pb est toujours présente sur les Effialiation (APP-26707).

Pour moi la correction que j'ai fait dans ce jira(APP-26707) n'a rien avoir , j'ai juste fait en sorte qu'on vois un seul tag lors de première achat. Donc le pb doit être toujours d'actualité.


Commentaire de Olga Costa [ 08/déc./09 17:08 ]
Si non Arnaud tu peux peut être dire plus sur le sujet :)
Commentaire de Arnaud Forgues [ 08/déc./09 17:27 ]
Malheureusement non, je ne peux pas en dire plus, car même si, comme dit Alex "panier --> pôle TX", ce genre de chose n'est absolument pas géré par le pôle TX. Il s'agit de fonctionnalités (tags, affiliation ...) gérées par le pôle contenu / param pour des demandes market.
Commentaire de Mathilde Caby [ 08/déc./09 17:34 ]
Bonjour Olga,

Nous ne constatons plus se décalage entre plateforme et bi depuis.
Ce phénomène semble donc avoir disparu.

Peut-on attendre lundi prochain: je ferai un extract de tous les paniers des 15 premiers jours de décembre et vérifirer l'ensemble des montants.


Ca vous va?
Commentaire de Olga Costa [ 16/déc./09 10:45 ]
Mathilde?
Commentaire de Jonathan Gorges [ 16/déc./09 14:26 ]
Bonjour,

Nous traitons ce point avec Mathilde demain matin, dès son retour.

Merci d'avance pour tout.

JG
Commentaire de Olga Costa [ 04/janv./10 17:38 ]
des news?
Commentaire de Jonathan Gorges [ 04/janv./10 17:46 ]
Hello,

Le problème semble ne plus se produire.

Vous pouvez fermer le Jira.

Merci




[APP-27428] Bug sur le TAG Affilinet depuis le 9/11/2009: ce n'est plus la commission qui remonte chez le partenaire mais le volume d'affaire! Création: 27/nov./09 09:28  Mise à jour: 22/déc./09 14:36  Résolue: 16/déc./09 10:45

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation, Infoglue
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 58.0.1.1

Type: Bogue Priorité: Critique
Rapporteur: Mathilde Caby Attribution: Swan Desportes
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Affilinet extract panier novembre 2009 avec correction.xlsx     Microsoft Excel Affilinet extract panier novembre 2009.xlsx     Microsoft Excel Effiliation extract panier novembre 2009 qui remontent en montant du panier.xlsx    
Pays:
FRA - France
Projets PM: *** CHASSE ***

 Description   
Bonjour,

Nous constatons un changement sur le TAG Affilinet depuis le 9/11/2009 au matin:
Depuis le 1er novembre c'était la commission qui remontait dans le TAG et suite à un bug , depuis cette date, c'est le volume d'affaire qui remonte à nouveau.

Nous ne constatons pas le problème sur les autres plateformes d'affiliation.
Merci d'avance pour le traitement de ce problème
Mathilde

 Commentaires   
Commentaire de Mathilde Caby [ 27/nov./09 09:41 ]
Voici le fichier des paniers remontant sur l'extranet de la plateforme Affilinet pour le mois de novembre avec les montants correspondant aux paniers.


Commentaire de Marion Anfreville [ 27/nov./09 09:45 ]
Semble être lié aux modifications qui sont passées pur Effiliation le 10/11 => APP-27074.
Commentaire de Marion Anfreville [ 27/nov./09 09:48 ]
Erreur de ma part, la modif que j'indique concerne effiliation (et pas affilinet)...
Commentaire de Marion Anfreville [ 27/nov./09 12:00 ]
Vu avec Mathilde. Il semble que le problème s'est rectifié tout seul à partir du 23/11.

On ne sait pas d'où vient le problème.

Est-ce que tu as trouvé d'autres cas ?
Commentaire de Mathilde Caby [ 27/nov./09 12:37 ]
Voici les paniers de chez Effiliation qui sont remontés en montant du panier : se sont des bugs mais ils sont relatifs au vue de la somme des transactions Effiliation
Commentaire de Mathilde Caby [ 27/nov./09 17:12 ]
J'ai fait le traitement complet des paniers de Affilinet pour le mois de novembre.
Il y a dans le fichier: le numéro de panier, la date du panier, le montant qui remonte sur l'extranet de la plateforme du partenaire, le montant de la commission bi , la différence entre les deux.
Quand le montant n'est pas égale à 0 c'est qu'il y a un problème dans le Tag

Mathilde
Commentaire de Renaud Dierickx [ 27/nov./09 17:50 ]
On attend le retour de Swan lundi.
Je ne vois pas ce qui s'est passé...
Commentaire de Swan Desportes [ 02/déc./09 15:52 ]
Pour être plus précis, est ce que le problème court du 10/11 - 5h du mat --> 24/11 - 5h du mat ?
Commentaire de Mathilde Caby [ 02/déc./09 17:55 ]
Non il y a quelques paniers qui sont remontés avec le montant panier également en dehors de cette période.
exemple: n° 77616670

Mathilde
Commentaire de Jérôme Viviès [ 08/déc./09 15:55 ]
Toujours critique comme demande ?
On fait quoi là-dessus ?
Commentaire de Olga Costa [ 11/déc./09 10:26 ]
Swan je t'assigne le jira car j'ai essayé de croiser de mon côté mais je ne vois pas pk ce problème est apparut. Les dates correspondent pas à de dumps. (07/11-26/11). Je sais pas si vous pouvez dire plus en dev. Sinon on ferme le jira
Merci
Commentaire de Swan Desportes [ 16/déc./09 09:16 ]
Pour qu'un tel bug se produise, il ne peut s'agir que d'un problème de contenus IG. Soit un problème de mélange dans les dates de publication, soit de mélange dans les dumps. Quoiqu'il en soit, tracer l'origine du problème sera très compliqué et chronophage. Donc je propose d'en rester là.
Principaux enseignements :
- les demandes de param nécessitent un traitement particulier, une recette plus rigoureuse
- il faudrait réhabiliter les tests de non reg sur les trackings. Pour cela, il faut bien travailler avec CGA en amont pour voir ce qu'il est possible de mettre en place.

[CAJ2009Q4CTN]
Commentaire de Christophe Garcia [ 16/déc./09 10:21 ]
MDPLVC




[APP-27696] [Hors Version] Paniers avec montants CBV capturés sans cbv créé Création: 16/déc./09 18:15  Mise à jour: 22/mars/10 10:58  Résolue: 29/janv./10 16:22

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 65.0.0 (TX-M)

Type: Bogue Priorité: Majeur
Rapporteur: Julien Girardet Attribution: Arnaud Forgues
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: Text File Bug_CBV_sql.txt     Microsoft Excel BUG_PCH_CBV.xls     Microsoft Excel BUG_PCH_CBV_221209.xls     Microsoft Excel BUG_PCH_ENMPTIED_CBV.xls     Microsoft Excel BUG_PCH_ENMPTIED_CBV_221209.xls     Text File purchase_id.txt     Microsoft Excel purchase_id.xls    
Liens des demandes:
Duplicate
a pour doublon APP-27771 contrat bris/vol prélevé alors que op... Fermé
Similaire
similaire à APP-27471 pblème sur capture denied > SIPS capt... Fermé
similaire à APP-27702 [Hors Version] différence de montant ... Fermé
similaire à APP-28183 Alertes nagios "Calling WarrantyRuleL... Fermé
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-27747 [Bug CBV Post V58] Correction du code Sub-bug Fermé Arnaud Forgues  
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***

 Description   
Salut,

Un certain nombre de paniers (+ 900 depuis debut decembre) ont des montants CBV capturés, or aucun cbv n'est créé.
Par contre le cbv a bien été souscrit par le user (presence de l'evenement "Souscription de garantie")

exemple :
http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=79535334
http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=79536347
http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=79528429
...


 Commentaires   
Commentaire de Arnaud Forgues [ 16/déc./09 18:50 ]
Est-il possible d'avoir un fichier excel en PJ de ce JIRA avec les fameux 500 panier concernés ? Ainsi cela permettrait d'identifier si ce pb concerne uniquement les CBV non pré-coché à la base (ie : prix < 5 ¿) ou pas.

Merci
Commentaire de Julien Girardet [ 16/déc./09 18:58 ]
liste des purchase_id concernés par le bug cbv
Commentaire de Julien Girardet [ 16/déc./09 18:59 ]
en excel
Commentaire de Julien Girardet [ 17/déc./09 14:12 ]
Liste des paniers capturés avec montants CBV capturés mais sans CBV créé
=> depuis 01/11/09
Commentaire de Julien Girardet [ 17/déc./09 14:13 ]
Liste des paniers annulés avec montants CBV capturés mais sans CBV créé
=> depuis 01/11/09
Commentaire de Julien Girardet [ 22/déc./09 17:40 ]
Liste des paniers capturés victimes du bug depuis 02/12/09 05h00
Commentaire de Julien Girardet [ 22/déc./09 17:46 ]
Liste des paniers annulés victimes du bug depuis 02/12/09 05h00
Commentaire de Habib-Sylvain Gourguet [ 23/déc./09 09:58 ]
Cas rencontré sur un cancelled :

http://bo.priceminister.com/purchase_back?action=purchaseview&purchaseid=79845782

Le montant du CBV est tout de même prélevé sur le PMV :

http://bo.priceminister.com/wallet?action=view&opid=521711494
Commentaire de Arnaud Forgues [ 29/janv./10 16:21 ]
Ci-dessous les derniers échanges/conclusions avec les BOW concernés (Thomas / Julien / Philippe) :

Thomas :
- Un client qui aurait pris un cbv lors de la période du bug retrouvera t-il dans son suivi de commande la possibilité de le faire jouer ?
- Le SAV est il au courant ?
- En avez vous parlé à un référent biz autre que moi par mail ? pkr ou autre ? pour qu'on puisse décider des suites à donner à ce bug ?

Arnaud:
Voici enfin des suites concernant le bug CBV du mois de décembre dernier :
Pour répondre à Thomas,
- A priori non, le lien de déclaration de sinistre ne devait pas s'afficher dans le « suivi article acheté ». Cependant le mail de bilan de commande précisait bien le montant du CBV payé ainsi qu'un lien d'aide/information
- Oui, le SAV est au courant et a géré le remboursement des 98 comptes pour lesquels les paniers ont été totalement annulés avec prélèvement du CBV
- Tout à fait, Philippe était dans la boucle depuis un moment à cause des écarts générés sur la dette vendeur.

Concernant les suites à donner à ce bug, j'ai vu Philippe avant-hier, et la décision est de ne rien faire.
- En effet, si on décidait de rembourser toutes les garanties non créées (malgré un prélèvement), cela reviendrait à générer 1497 opérations et alerter donc 1497 acheteurs qu'il y a eu un problème, alors que pour la majorité (totalité) d'entre eux, ils n'ont pas voulu / eu besoin de faire jouer leur CBV et n'ont donc pas contacté le SAV. Ce serait donc risqué car cela susciterait trop de questions.
- Si on souhaitait recréer à posteriori les garanties, cela représenterait pas mal de travail côté dev puis côté BI/Compta pour la prise en compte de tout cela pour la dette vendeur. Et sachant l'écart généré par rapport au revenus global CBV du mois de décembre, ce ne serait pas pragmatique.

Côté chiffre, on constate donc :
- 98 paniers annulés avec CBV prélevé &#61672; le SAV les a tous remboursés via un crédit PMV (au total environ 68 euros)
- 1313 paniers (soit environ 2500 articles) avec CBV prélevés mais non créés &#61672; on ne fait rien mais pas de manque à gagner
- 5763 paniers (soit environ 12253 articles) avec CBV éligibles mais non créés ni prélevés &#61672; manque à gagner

D'un point de vue taux de souscription, on avait donc au mois de décembre pour les articles < 5 euros éligibles au CBV :
- un total de 288 980 articles
- dans les faits, 5 280 CBV réellement créés, soit un taux de 1.83%
- En réalité 2 468 CBV prélevés (mais non créés) en plus, soit un taux de 2.68%
- Un total de 12 253 CBV éligibles mais non créés ni prélevés, soit un taux théorique de 6.9% &#61672; on a donc un manque a gagner sur les articles de moins de 5 euros de 4,2%


NB : en PJ (Bug_CBV_sql.txt), le fichier d'analyse qui a permis d'analyser les impacts du bug CBV.
Commentaire de Arnaud Forgues [ 01/févr./10 10:45 ]
CAJ2010Q1TX




[APP-28262] Laredoute redirige vers croix-rouge... Création: 10/févr./10 14:25  Mise à jour: 11/févr./10 09:29  Résolue: 10/févr./10 14:39

Etat: Fermé
Projet: Application PriceMinister
Composants: Cobrandings
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 62.0.0 (NAV-A)

Type: Bogue Priorité: Critique
Rapporteur: Fabrice Feugas Attribution: Patrice Boulanger
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***

 Description   
Depuis les emails ou même quand on va sur http://laredoute-occasion.priceminister.com/ on est redirigé (une fois de temps en temps) vers pricesolidaire...

 Commentaires   
Commentaire de Patrice Boulanger [ 10/févr./10 14:32 ]
Le problème est sur le serveur Phaeton, le fichier du virtualhost areoudte-occasion est vide:

[adminpm@phaeton available]$ ll
total 76
drwxrwxr-x 2 adminpm adminpm 4096 May 11 2009 .
drwxrwxr-x 4 adminpm adminpm 4096 May 4 2009 ..
-rw-rw-r-- 1 adminpm adminpm 609 Oct 22 13:49 bi.priceminister.com
-rw-rw-r-- 1 adminpm adminpm 2417 May 4 2009 bo.priceminister.com
-rw-rw-r-- 1 adminpm adminpm 1493 May 4 2009 croix-rouge.priceminister.com
-rw-r--r-- 1 adminpm adminpm 2321 May 4 2009 epik.priceminister.com
-rw-r--r-- 1 adminpm adminpm 2350 May 4 2009 francemobiles.priceminister.com
-rw-r--r-- 1 adminpm adminpm 2355 May 4 2009 freesurf.priceminister.com
-rw-r--r-- 1 adminpm adminpm 328 May 4 2009 ie8.priceminister.com
-rw-rw-r-- 1 adminpm adminpm 333 May 4 2009 img.priceminister.com
-rw-rw-r-- 1 adminpm adminpm 524 May 4 2009 intra.priceminister.com
-rw-r--r-- 1 adminpm adminpm 2819 May 4 2009 journauxdumidi.priceminister.com
-rw-rw-r-- 1 adminpm adminpm 2524 May 4 2009 koobuycity.priceminister.com
-rw-r--r-- 1 adminpm adminpm 0 Jan 26 15:59 laredoute-occasion.priceminister.com
-rw-r--r-- 1 adminpm adminpm 2514 May 4 2009 lesbonnesaffairesduprogres.priceminister.com
-rw-r--r-- 1 adminpm adminpm 2500 May 4 2009 mobilesachat.priceminister.com
-rw-r--r-- 1 adminpm adminpm 2303 May 4 2009 nicematin.priceminister.com
-rw-rw-r-- 1 adminpm adminpm 2765 May 4 2009 occasion.camif.fr
-rw-rw-r-- 1 adminpm adminpm 3758 Sep 21 17:12 preview.priceminister.com
-rw-r--r-- 1 adminpm adminpm 2380 May 4 2009 sfr.priceminister.com

Apparemment, effacé le 26/01 à 15h59.

Commentaire de Patrice Boulanger [ 10/févr./10 14:37 ]
C'est corrigé
Commentaire de Fabrice Feugas [ 10/févr./10 14:38 ]
Ça vient d'où cette modification ?

Quand pourra t-on rétablir le bon fichier ? Au redémarrage demain ?
Commentaire de Christophe Garcia [ 10/févr./10 14:38 ]
MDPLVC
Commentaire de Fabrice Feugas [ 10/févr./10 14:39 ]
Merci Patrice. Je pense que ce JIRA fait partie de ceux qui auront eu la durée de vie la plus courte :)
Commentaire de Cédric Goldovsky [ 11/févr./10 09:29 ]
@ Fabrice : pas forcément la durée la plus courte puisque je le ferme seulement maintenant ^^




[BIN-647] Impoossible de planifier le rapport import : Import success rate vs revenue Création: 29/janv./10 11:30  Mise à jour: 25/févr./10 17:11  Résolue: 03/févr./10 18:53

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Frédéric Nahum Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Pour fournir les chiffres à la direction et au commerciaux sur le C.A que génère les Imports, j'aimerais planifier sur un mois, un trimestre et un an le rapport :Import success rate vs revenue

Mais comme vu avec cyril le rapport tombe ne echec.

 Commentaires   
Commentaire de Jérôme Viviès [ 03/févr./10 15:11 ]
Coucou,
Savez-vous quand vous pourriez avancer là-dessus ?
Ou si ça ne sera pas du tout possible ?
Merci ! :)
Commentaire de Dalila Belkebir [ 03/févr./10 15:18 ]
Hello,

Je regarde ça dans l'après midi. Promis.

Cdlt,
Dalila.
Commentaire de Dalila Belkebir [ 03/févr./10 18:53 ]
A priori quand je planifie sur un seul mois cela passe. En sélectionnant tous les login (% dans l'invite). en 3 minutes
A partir de 2 mois la quantité de données brassées et trop grande et le rapport plante (beaucoup de mise en forme et de calculs aussi dans le rapport).
=> la problématique est pour la récupération de l'historique. Pour un usage mensuel le rapport est OK en planif.

La solution :
- planifier chaque lancement sur un seul mois pour avoir les infos de l'historique
- et planifier un lancement à partir de maintenant pour avoir les données sur un mois tous les mois.

Vous pouvez déjà récupérer les infos que j'ai généré sur l'historique de planification.

Cela vous convient ?

Cdlt,
Dalila.
Commentaire de Jérôme Viviès [ 04/févr./10 09:47 ]
Ok, on n'a visiblement pas trop le choix (!)
On va se débrouiller avec l'échelon mensuel...
Merci !
Commentaire de Dalila Belkebir [ 04/févr./10 11:28 ]
Je viens de refaire des tests en lançant le rapport sur un trimestre et cela passe en 8 à 10 min... Donc a priori si cela plante c'est aussi dû à une forte activité sur le BI. Il faudrait faire des tests de planif sur certains créneaux horaires pour s'assurer d'une disponibilité du système sur des requêtes sur une période plus longue.

Jette un oeil sur mes dernières planifs STP.

Par contre, le besoin que tu exprimes aujourd'hui est un besoin non opérationnel ie un besoin plutôt global : bilan sur un trimestre, et sur tous les logins.
Le rapport a été initialement développé pour un suivi beaucoup plus précis et détaillé : focus possible sur un user, drill down etc...

Si vous avez besoin d'un rapport plus global alors il nous faut vous mettre en place un nouveau rapport. Par exemple un rapport sans l'invite sur le login et une mise en forme plus basique avec juste les indicateurs financiers.
Si tu le souhaite tu peux nous faire un JIRA dans ce sens et nous planifierons sa réalisation.

A ta dispo si tu souhaites en parler.

Cdlt,
Dalila.
Commentaire de Dalila Belkebir [ 23/févr./10 17:36 ]
Hello Frédéric & Jérôme,

Pouvez-vous me valider ce JIRA pour clôture?

J'ai notamment vu la création du nouveau JIRA http://pricejira/browse/BIN-650 pour la création d'un nouveau rapport.
Nous vous ferons un retour sur la planif de ce besoin.

Merci de votre validation.

cdlt,
Dalila.
Commentaire de Jérôme Viviès [ 25/févr./10 17:00 ]
Ok, comme vu ensemble on a plutôt besoin d'un nouveau rapport - cf BIN-650.
Donc cette demande-ci est bien close :)




[APP-28255] Erreur JSON : Caractères spéciaux ? Création: 10/févr./10 10:15  Mise à jour: 02/mars/10 16:32  Résolue: 25/févr./10 14:41

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 61.0.1.2
Version(s) corrigée(s): 63.0.1

Type: Bogue Priorité: Mineur
Rapporteur: Christophe Garcia Attribution: Thierry Leforestier
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***

 Description   
2010-02-09 06:35:53,260 INFO [-Processor25] 66.249.71.46 - >>> GET http://www.priceminister.com/offer/buy/60644181/Canon-100-200-mm-f-4-5-AF-EOS-Objectif.html
2010-02-09 06:35:53,344 ERROR [-Processor25] 66.249.71.46 - Syntax error in dynamo JSON code : [{"label": "Eos 30 + objectif", "url": "/offer/buy/82170961/canon-eos-30-object
if-28-105-usm-grip-bp-300-photo-argentique.html", "edito": "Canon 100 200"},{"label": "Vente occasion eos },{"label": "Eos objectif m42", "url": "/offer/buy/51667973/canon-EOS-B
ague-adaptation-objectif-42-Objectif.html", "edito": "Objectif canon 100-200"},{"label": "Eos 300 objectif", "url": "/offer/buy/57575538/Canon-eos-300-objectif-28-90-canon-objec
tif-90-300-canon-Photo-Argentique.html", "edito": "Prix objectif canon 100-200"},{"label": "Eos 1000 objectif", "url": "/offer/buy/1677352/Canon-EOS-1000-FN-Photo-Argentique.htm
l", "edito": "100/200 canon"},{"label": "Eos objectif 50 f 1.8 occasion", "url": "/offer/buy/2588406/Canon-Objectif-50-mm-f-1-8-II-Canon-EF-Objectif.html", "edito": "Objectif 10
0-200"},{"edito": "Objectif canon autofocus 200mm"}]
2010-02-09 06:35:53,541 INFO [-Processor25] 66.249.71.46 - <<< [281 ms] GET http://www.priceminister.com/offer/buy/60644181/Canon-100-200-mm-f-4-5-AF-EOS-Objectif.html

================================

2010-02-09 09:57:37,475 INFO [-Processor13] 66.249.71.247 - >>> GET http://www.priceminister.com/offer/buy/17324421/Ub40-Homegrown-In-Holland-Live-DVD-Zone-1.html
2010-02-09 09:57:37,650 ERROR [-Processor13] 66.249.71.247 - Syntax error in dynamo JSON code : [{"label": "Ub40 - live", "url": "/offer/buy/994426/Ub40-Ub40-Live-CD-Album.htm
l", "edito": "Ub40 - h2o (live)"},{"label": "Live 1990 holland", "url": "/offer/buy/52680658/Mano-Negra-Manu-Chao-Live-In-Holland-1990-Cd-Album-Cassettes-Mini-disques-Laser-disq
ues.html", "edito": "Ub 40"},{"label": "Dvd achat videokid holland", "url": "/offer/buy/1391651/Videokid-VHS.html"},{"label": "Dvd professeur holland", "url": "/offer/buy/148038
7/Professeur-Holland-DVD-Zone-2.html"},{"label": "Acheter ub40", "url": "/offer/buy/15207152/Ub-40-Ub-40-File-CD-Album.html"},{"label": "Dvd opus de holland", "url": "/offer/buy
/17699/Kamen-Michael-Mr-Holland-s-Opus-Professeur-Holland-CD-Album.html"},{"label": "Ub40 en live", "url": "/offer/buy/1902287/Ub40-Rockpalast-Live-DVD-Zone-1.html"},{"label":
"Cd ub40 live", "url": "/offer/buy/20385/Ub-40-Live-CD-Album.html"},{"label": "Ub40 - h²o {live},{"label": "Cover ub40 live in holland", "url": "/offer/buy/48575776/Ub-40-Cover
-Up-CD-Album.html"}]
2010-02-09 09:57:37,827 INFO [-Processor13] 66.249.71.247 - <<< [352 ms] GET http://www.priceminister.com/offer/buy/17324421/Ub40-Homegrown-In-Holland-Live-DVD-Zone-1.html

=======================================

2010-02-09 12:15:17,690 INFO [-Processor75] 192.54.193.26 - >>> GET http://www.priceminister.com/offer/buy/680071/Dogna-Michel-Prenez-En-Main-Votre-Sante-Toutes-Les-Maladies
-Courantes-Livre.html
2010-02-09 12:15:17,886 ERROR [-Processor75] 192.54.193.26 - Syntax error in dynamo JSON code : [{"label": "Michel dogna pancreatine", "url": "/offer/buy/82420972/michel-dogna
-pratique-de-la-cure-gerson-et-kelley-60-annees-de-succes-therapeutiques-le-saviez-vous-livre.html", "edito": "Michel dogna prenez en main votre santé"},{"label": "Bélanger mich
el les ce et la santé", "url": "/offer/buy/831131/Belanger-Michel-Droit-International-De-Sante-Livre.html", "edito": "Livre prenez en main votre sente vol 2"},{"label": "Tous le
s cd a la vente de michel dogna", "url": "/s/ann%E9es+60", "edito": "Prenez en main votre santé de michel dogna"},{"label": "Livre du dr dogna", "url": "/s/michel+dogna", "edito
": "Prenez votre vie en main dogna"},{"label": "Michel dogna et la gemmotherapie", "url": "/offer/buy/59516591/Dogna-Michel-Gemmotherapie-Alcoolatures-Meres-Livre.html", "edito"
: "Michel dogna prenez votre santé en main"},{"label": "Livreprenez en main votre santé de michel dogna", "url": "/offer/buy/6313129/Dogna-Michel-Prenez-En-Main-Votre-Sante-T-2-
Nouvelles-Decouvertes-Livre.html", "edito": "Prenez votre santé en main michel dogna"},{"label": "élixir minéral lipome dogna michel", "url": "/offer/buy/554834/Dogna-Michel-Eli
xirs-De-Fleurs-Homoepathiques-Livre.html", "edito": "{livre, prenez en main votre santé, michel dogna, ed. guy trédaniel editeur},{"label": "Livre michel dogna occasion", "url":
 "/offer/buy/17525200/Dogna-Michel-Grands-Remedes-En-Naturopathie-Livre.html", "edito": "Prenez votre santé en main volume i de michel dogna"},{"label": "Qui est michel dogna",
"url": "/offer/buy/46905553/Dogna-Michel-Remedes-Peu-Connus-En-Homeopathie-Livre.html", "edito": "Prenez en main votre santé michel dogna"},{"label": "Michel dogna cd", "url": "
/offer/buy/48924205/Dogna-Michel-L-amour-Vainqueur-CD-Album.html", "edito": "Prenez en main votre santé 4éme édition"}]


 Commentaires   
Commentaire de Thierry Leforestier [ 10/févr./10 10:54 ]
il s'agit de caractères "{}" présents dans les mots clefs. Je le traite avec la prochaine turbinamo, ce sont normalement des cas a la marge.

Thierry
Commentaire de Christophe Garcia [ 10/févr./10 12:56 ]
En voilà d'autres (peut-être me même pb)

{"label": "Atlas jazz django", "url": "/s/jazz+blues+collection", "edito": "Modern jazz quartet django cd occasion"},{"label": "Micro jazz bass original usa", "url": "/offer/buy/62144345/Micro-De-Basse-Electrique-Vintage-Jazz-Bass-Us-Position-Manche-Fender-Instrument.html"},{"label": "Jazz bass reissue 62 usa", "url": "/offer/buy/63080618/Fender-Jazz-Bass-Usa-Reissue-62---Basse-Electrique-Fender-Instrument.html"},{"label": "Jazz story in usa", "url": "/offer/buy/52942857/Harlem-In-Montmartre-A-Paris-Jazz-Story-Between-The-Great-Wars-Livre.html"},{"label": "Cordier jazz django", "url": "/offer/buy/54265448/Jazz-Manouche-La-Grande-Aventure-Du-Swing-Gitan-De-Django-Reinhardt-A-Tchavolo-Schmitt-Livre.html"},{"label": "Django{% import %},{"label": "Jazz impression of usa brubeck", "url": "/offer/buy/55476965/Brubeck-Dave-Quartet-Jazz-Impressions-Of-New-York-33-Tours.html"},{"label": "Modern jazz quartet django", "url": "/offer/buy/56097813/Modern-Jazz-Quartet-Modern-Jazz-Quartet-Django-25-Cm-Barclay-84-007-25-cm.html"},{"label": "Le jazz de a à z django", "url": "/offer/buy/138653/Reinhardt-Django-Le-Jazz-De-A-A-Z-CD-Album.html"},{"label": "Rythme jazz manouche django reinhart", "url": "/offer/buy/2031708/Antonietto-Alain-Django-Reinhardt-Rythmes-Futurs-Livre.html"}]

{"label": "Attention fillette livre", "url": "/offer/buy/81122691/granotier-sylvie-mefie-toi-fillette-livre.html"},{"label": "L'attention psychologie selon les modalités deutsh and deutsh", "url": "/offer/buy/66775379/La-Psychologie-Des-Femmes-Tome-I-Enfance-Et-Adolescence-Livre.html"},{"label": "Inhibition neuropsychologie", "url": "/offer/buy/8626776/Coyet-Neuropsychologie-Des-Fonctions-Executives-Livre.html"},{"label": "Attention visuelle livre", "url": "/offer/buy/61626792/Michael-George-Neuroscience-Cognitive-De-L-attention-Visuelle-Livre.html"},{"label": "Orientalisme latent", "url": "/offer/buy/6338190/Said-Edward-W-L-orientalisme-L-orient-Cree-Par-L-occident-Livre.html"},{"label": "Inhibition pathologique", "url": "/offer/buy/1318769/Boujon-Christophe-L-inhibition-Au-Carrefour-Des-Neurosciences-Livre.html"},{"label": "Moutier inhibition", "url": "/offer/buy/1384547/Moutier-Sylvain-Inhibition-Et-Biais-De-Raisonnement-Chez-L-enfant-Et-L-adulte-Livre.html"},{"label": "Riffaterre intertexte latent", "url": "/offer/buy/215641/Riffaterre-Michael-Semiotique-De-La-Poesie-Livre.html"},{"label": "Inhibition laborit", "url": "/offer/buy/342756/Laborit-Henri-Inhibition-De-L-action-Livre.html"},{"label": "Martingales and {m}]

{"label": "Avis jean prieur", "url": "/offer/buy/6893114/Prieur-Jean-Les-Temoins-De-L-invisible-Livre.html", "edito": "Saints et saintes photos"},{"label": "Cet audela qui nous attend de jean prieur", "url": "/offer/buy/6893115/Prieur-Jean-Cet-Au-Dela-Qui-Nous-Attend-Livre.html", "edito": "Jean prieur la fontaine de siloé"},{"label": "Chant religieux: saints et saintes de dieu", "url": "/offer/buy/73811318/Saints-Et-Saintes-Quarante-Chants-Volume-1-N-1-Revue.html"},{"label": "Saints et saintes", "url": "/offer/buy/886305/Prieur-Vuillier-Saints-Et-Saintes-De-Savoie-Livre.html"},{"label": "Hitler médium de satan jean prieur", "url": "/offer/buy/974821/Prieur-Jean-Hitler-Medium-De-Satan-Livre.html"},{"label": "Livres de jean prieur j ai lu", "url": "/offer/buy/980694/Prieur-Jean-Hitler-Et-La-Guerre-Luciferienne-Livre.html"},{"label": "Saints et saintes de dieu", "url": "/offer/buy/49395667/Molin-Pierre-Sainte-Vierge-Marie-Saints-Et-Saintes-De-Dieu-Livre.html"},{"label": "Livres avec les saints et saintes { prieres},{"label": "Le pay d apres de jean prieur", "url": "/offer/buy/16994245/Prieur-Jean-Les-Maitres-De-La-Conscience-Planetaire-Livre.html"},{"label": "Vidéo de biographie de saints et saintes", "url": "/offer/buy/46920426/Collection-Vie-Des-Saints-Ste-Bernadette-Soubirous-DVD-Zone-2.html"}]

{"label": "Barbara buy", "url": "/offer/buy/81525120/tailleur-barbara-bui-pantalon-et-veste-surpique-turquoise-t-34-36-pret-a-porter.html", "edito": "Augustin barbara"},{"label": "Augustin boujeka", "url": "/s/augustin+boujeka"},{"label": "Aynes augustin", "url": "/s/ayn%E8s+augustin"},{"label": "Barbara castello", "url": "/s/barbara+castello"},{"label": "{augustin lespinasse},{"label": "Augustin lemann", "url": "/s/m+l+abb%E9+augustin+lemann"},{"label": "Augustin dupré", "url": "/offer/buy/600073/Collectif-Augustin-Dupre-1748-1833-Graveur-General-Des-Monnaies-De-France-De-1791-A-1803-Livre.html"},{"label": "Augustin grimault", "url": "/offer/buy/62886292/Histoire-De-L-eglise-Catholique-Au-Senegal---Du-Milieu-Du-Xve-Siecle-A-L-aube-Du-Troisieme-Millenaire-Livre.html"},{"label": "Augustin giovannoni", "url": "/offer/buy/529916/Giovannoni-Augustin-Immanence-Et-Finitude-Chez-Spinoza-Etudes-Sur-L-idee-De-Constitution-Dans-L-ethique-Livre.html"},{"label": "Barbara 47", "url": "/offer/buy/2440684/Collectif-Platine-N-47-Le-Mystere-Barbara-Revelations-Exclusives-Revue.html"}]

{"label": "Clinical implications of attachment", "url": "/offer/buy/79934046/-clinical-implications-of-attachment-child-psychology-livre.html"},{"label": "Grounded theory research", "url": "/offer/buy/67265070/Discovery-Of-Grounded-Theory-Strategies-For-Qualitative-Research-Livre.html"},{"label": "G.i. barenblatt scaling, self-similarity and intermediate asymptotics", "url": "/offer/buy/74456063/Scaling-Self-Similarity-And-Intermediate-Asymptotics-Livre.html"},{"label": "Neuro-enhancement", "url": "/offer/buy/87541178/endruweit-meiken-prinzip-zukunft-im-dialog-mit-hans-jonas-livre.html"},{"label": "Geopolitical and geosecurity implications of globalization", "url": "/offer/buy/54199246/The-Geopolitical-And-Geosecurity-Implications-Of-Globalization-Livre.html"},{"label": "Martingales and {m}]

{"label": "Edouard hermes", "url": "/offer/buy/68410163/J-ai-Vu-J-ai-Entendu-Livre.html", "edito": "Les grands initiés d'edouard schuré"},{"label": "Jardin de pythagore + hermes", "url": "/s/hermes", "edito": "Edouard schuré"},{"label": "Moise pythagore socrate jesus mahomet", "url": "/s/les+grands+initi%E9s", "edito": "Les grand initie pythagore"},{"label": "Date mort de moise par rapport a jesus", "url": "/offer/buy/50971356/Du-Sinai-A-La-Mer-Morte-De-Moise-A-Jesus-Livre.html", "edito": "Krishma"},{"label": "Les grands initiés schuré", "url": "/offer/buy/19486207/Edouard-Schure-Les-Grands-Inities-Esquisse-De-L-Histoire-Secrete-Des-Religions-Rama-Krishma-Hermes-Moise-Orphee-Pythagore-Platon-Jesus-Livre.html", "edito": "Grands initiés (les), edouard schuré, ed. librairie académique perrin},{"label": "Schure grands inities 1921", "url": "/offer/buy/2159782/Schure-Edouard-Les-Grands-Inities-Esquisse-Ded-L-histoire-Secrete-Des-Religions-Rama-Krishna-Hermes-Moise-Orphee-Pytagore-Platon-Jesus-Livre-ancien.html", "edito": "Cinq grands initiés"},{"label": "Synthèse les grands initiés edouard schuré", "url": "/offer/buy/385699/Schure-Edouard-Les-Grands-Inities-Integrale-Livre.html", "edito": "La vérité des grands initiés"},{"label": "Pythagore et les grands inities", "url": "/offer/buy/392823/Schure-Edouard-Les-Grands-Inities-Livre.html", "edito": "Schuré et les sens"},{"label": "Les grands inities jesus", "url": "/offer/buy/47257687/Les-Grands-Inities-Krishna-Jesus-Pythagore-Rama-Moise-Platon-Hermes-Orphee-Livre.html", "edito": "Livre,grands initiés (les) edouard schuré, ed. librairie académique périn"},{"edito": "Les grand initiés (edouard schuré"}]

{"label": "Hutin destock", "url": "/s/benoit+hutin", "edito": "Serge hutin"},{"label": "Gnostiques hutin", "url": "/offer/buy/61082876/Hutin-Serge-Les-Gnostiques-Livre.html", "edito": "Serge hutin livres"},{"label": "Serge hutin societé secrete", "url": "/offer/buy/6563541/Hutin-Serge-Gouvernants-Invisibles-Et-Societe-Secretes-Livre.html", "edito": "Les gouvernants invisibls hutin"},{"label": "Jpg martignoni hutin", "url": "/offer/buy/496739/Martignoni-Hutin-Jean-Pierre-Ethno-Sociologie-Des-Machines-A-Sous-Que-Le-Hasard-Vous-Serve-Mais-Preparez-Vous-A-L-accueillir-Livre.html", "edito": "Maison serge hutin"},{"label": "Jp hutin", "url": "/offer/buy/51580087/Mabrouk-Chien-D-une-Vie-Livre.html", "edito": "Histoire de l'astrologie: science ou superstition serge hutin"},{"label": "Serge hutin hommes et civilisation", "url": "/offer/buy/53250179/Hommes-Et-Civilisations-Fantastiques-Livre.html", "edito": "Livres de serge hutin"},{"label": "Baudouin bonsergent serge hutin", "url": "/offer/buy/1184046/Nostradamus-Les-Propheties-De-Nostradamus-Texte-Integral-Livre.html", "edito": "Livre, hommes et civilisations fantastiques, serge hutin, ed. j'ai lu},{"label": "L'ésotérisme de l'histoire serge hutin", "url": "/offer/buy/1211794/Hutin-Serge-L-esoterisme-De-L-histoire-Livre.html"},{"label": "Homme et civilisation fantastique serge hutin", "url": "/offer/buy/1814566/Hutin-Serge-Hommes-Et-Civilisations-Fantastiques-Livre.html"},{"label": "Serge hutin dedicace", "url": "/offer/buy/47232995/Hutin-Serge-L-amour-Magique-Revelations-Sur-Le-Tantrisme-Livre.html"}]

{"label": "Kryeon 2012", "url": "/offer/buy/57825411/Vers-2012-Tome-2-Au-Dela-Du-Voile-Des-Illusions-Et-De-La-Confusion-Kryeon-La-Fraternite-De-Lumiere-Soria-L-archange-Michael-Et-Amma-1cd-Audio-Livre.html", "edito": "Le retour édition kryéon"},{"label": "Kryeon 2009 partenaire avec le divin", "url": "/offer/buy/636444/Kryeon-Partenaire-Avec-Le-Divin-T-4-Livre.html", "edito": "{livre, messages de notre famille, kryeon, ed. ariane},{"label": "Parabole de kryeon", "url": "/offer/buy/636445/Kryeon-Le-Retour-Livre.html", "edito": "Kryeon occasion"},{"label": "Message kryeon", "url": "/offer/buy/636455/Carroll-Messages-De-La-Famille-T-5-Livre.html"},{"label": "Kryeon", "url": "/offer/buy/49285613/Kryeon-Kryeon-5-Messages-De-Notre-Famille-Livre.html"},{"label": "Meditation de kryeon", "url": "/offer/buy/51923060/Collectif-Kryeon-Adama-La-Fraternite-De-Lumiere-Soria-Hildon-Chandra-Et-Flex-Collectif-2007-Le-Retour-De-La-Lumiere-L-annee-Du-Discernement-Spirituel-Cd-De-Meditation-Livre.html"},{"label": "Carroll kryeon", "url": "/offer/buy/56163160/Kryeon-Tome-9-La-Levee-Du-Voile-L-apocalypse-De-La-Nouvelle-Energie-Livre.html"}]

{"label": "La captive de la voulte", "url": "/offer/buy/77805529/thibaudet-marguerite-le-coultre-henri-gheon-la-captive-de-la-voulte-livre-ancien.html"},{"label": "Cleopatre captive", "url": "/offer/buy/81835377/jodelle-etienne-cleopatre-captive-livre.html"},{"label": "La captive d'al-ankhara", "url": "/offer/buy/82420237/sandra-marton-la-captive-d-al-ankhara-livre.html"},{"label": "Priere du captif{de la captive},{"label": "Fauvette captive- battmann", "url": "/s/battmann+j+l"},{"label": "Captive 2", "url": "/offer/buy/5986303/Liberation-Captive-2-Jeu-Amiga-Cd-32.html"},{"label": "La captive des highlands", "url": "/offer/buy/61219419/Dickson-Helen-La-Captive-Des-Highlands-Livre.html"},{"label": "Captive enchainee", "url": "/offer/buy/61516483/Wirta-Guy-La-Captive-Enchainee-Livre.html"},{"label": "La captive d'istamboule résumé", "url": "/offer/buy/17707196/Ball-David-Le-Faucon-D-istanbul-T-2-Livre.html"},{"label": "La captive du donjon", "url": "/offer/buy/3659798/Phillips-Tori-La-Captive-Du-Donjon-Livre.html"}]

{"label": "La mouche qui a piqué koto", "url": "/offer/buy/82927935/le-sablier-la-mouche-qui-a-pique-koto-livre.html"},{"label": "La mouche pique", "url": "/offer/buy/969597/Mousset-Frederique-Mouche-Qui-A-Pique-Koto-Livre-Cd-Livre.html"},{"label": "Quelle mouche le pique", "url": "/offer/buy/61439258/Noll-Kangoo-Juniors-Tome-2---Quelle-Mouche-Te-Pique-Livre.html"},{"label": "Cédric 5 {quelle mouche le pique?},{"label": "Frédérique mousset", "url": "/offer/buy/537446/Mousset-Frederique-Chipote-Et-Patchouli-Livre.html"},{"label": "Cédric quelle mouche le pique?", "url": "/offer/buy/49146199/Cauvin-Raoul-Cedric-Quelle-Mouche-Le-Pique-Livre.html"}]

{"label": "Le larron", "url": "/offer/buy/78179452/larron-le-le-larron-cd-album.html", "edito": "Ultimates n°10"},{"label": "Ultimates 41", "url": "/offer/buy/82377383/ultimates-n-41-revue.html"},{"label": "Ultimates 30", "url": "/offer/buy/70762640/Lot-De-7-Ultimates-Du-N-30-Au-N-36-N-30-Ultimates-Revue.html"},{"label": "Ultimates 32", "url": "/s/ultimates+32+%E0+37++n%B0+6"},{"label": "Ultimates 15", "url": "/s/ultimates+n%B0+15+:+cauchemar(2)"},{"label": "Ultimates 42", "url": "/s/ultimates+x+men++n%B0+42"},{"label": "Ultimates 41 achat", "url": "/offer/buy/59458674/Collectif-Ultimate-X-Men-N-41-Cable-2-Revue.html"},{"label": "Ultimates {2°},{"label": "Ultimates 43", "url": "/offer/buy/61157296/Collectif-Ultimate-X-Men-N-43-Suspense-Revue.html"},{"label": "Bon larron", "url": "/offer/buy/657264/Frere-Stephane-Bon-Larron-Livre.html"}]

{"label": "Livre instrument de precision", "url": "/offer/buy/79633047/mitutoyo-m-instruments-de-precision-mecanique-optique-electronique-livre-ancien.html"},{"label": "Sector 200", "url": "/offer/buy/83767600/sector-200-montre.html"},{"label": "Examples of public sector marketing", "url": "/offer/buy/66638263/Marketing-In-The-Public-Sector-A-Roadmap-For-Improved-Performance-Livre.html"},{"label": "Democracy and the public service", "url": "/offer/buy/67250356/Democracy-And-The-Public-Service-Livre.html"},{"label": "Livre+vst instrument", "url": "/offer/buy/67352740/Basic-Vst-Instruments-Livre.html"},{"label": "Pa and instrument rack", "url": "/offer/buy/58402254/Korg-05r-W-Expandeur-1-2-Rack-Korg-Instrument.html"},{"label": "Xo: a theory of the morphology-syntax interface", "url": "/offer/buy/52856373/Xo-A-Theory-Of-The-Morphology-Syntax-Interface-Livre.html"},{"label": "Sector 620", "url": "/offer/buy/54887695/Bracelets-Montres-Sector-620-Ebel-Voyager-Tudor-Prince-Omega-Dynamic-Audemars-Piguet-Breitling-Callistino-Fred-Force-10-Carrera-Y-Carrera-Cartier-Pasha-Boucheron-Revue.html"},{"label": "Stiglitz public sector", "url": "/offer/buy/18633507/Joseph-Stiglitz-Economics-Of-The-Public-Sector-Livre.html"},{"label": "Martingales and {m}]

{"label": "Michel dogna pancreatine", "url": "/offer/buy/82420972/michel-dogna-pratique-de-la-cure-gerson-et-kelley-60-annees-de-succes-therapeutiques-le-saviez-vous-livre.html", "edito": "Michel dogna prenez en main votre santé"},{"label": "Bélanger michel les ce et la santé", "url": "/offer/buy/831131/Belanger-Michel-Droit-International-De-Sante-Livre.html", "edito": "Livre prenez en main votre sente vol 2"},{"label": "Tous les cd a la vente de michel dogna", "url": "/s/ann%E9es+60", "edito": "Prenez en main votre santé de michel dogna"},{"label": "Livre du dr dogna", "url": "/s/michel+dogna", "edito": "Prenez votre vie en main dogna"},{"label": "Michel dogna et la gemmotherapie", "url": "/offer/buy/59516591/Dogna-Michel-Gemmotherapie-Alcoolatures-Meres-Livre.html", "edito": "Michel dogna prenez votre santé en main"},{"label": "Livreprenez en main votre santé de michel dogna", "url": "/offer/buy/6313129/Dogna-Michel-Prenez-En-Main-Votre-Sante-T-2-Nouvelles-Decouvertes-Livre.html", "edito": "Prenez votre santé en main michel dogna"},{"label": "élixir minéral lipome dogna michel", "url": "/offer/buy/554834/Dogna-Michel-Elixirs-De-Fleurs-Homoepathiques-Livre.html", "edito": "{livre, prenez en main votre santé, michel dogna, ed. guy trédaniel editeur},{"label": "Livre michel dogna occasion", "url": "/offer/buy/17525200/Dogna-Michel-Grands-Remedes-En-Naturopathie-Livre.html", "edito": "Prenez votre santé en main volume i de michel dogna"},{"label": "Qui est michel dogna", "url": "/offer/buy/46905553/Dogna-Michel-Remedes-Peu-Connus-En-Homeopathie-Livre.html", "edito": "Prenez en main votre santé michel dogna"},{"label": "Michel dogna cd", "url": "/offer/buy/48924205/Dogna-Michel-L-amour-Vainqueur-CD-Album.html", "edito": "Prenez en main votre santé 4éme édition"}]

{"label": "Mondo et autres histoire clezio lullaby", "url": "/offer/buy/77358745/Mondo-Et-Autres-Histoires.html", "edito": "Mondo et autre histoire résumé"},{"label": "Le clézio jmg mondo et autres histoire resumer", "url": "/offer/buy/7284956/Le-Clezio-J-M-G-Mondo-Et-Autres-Histoires-Livre.html", "edito": "Fiche de lecture mondo et autres histoires"},{"label": "Jean-marie gustave le clézio mondo et autres histoires gratuit", "url": "/offer/buy/880825/Le-Clezio-Jean-Marie-Gustave-Mondo-Et-Autres-Histoires-Livre.html", "edito": "Lecture de mondo"},{"label": "Le clezio mondo gratuit", "url": "/offer/buy/63180570/Mondo-Et-Autres-Histoires-Livre.html", "edito": "Mondo le clezio questionnaire"},{"label": "Mondo et autres histoires le clezio", "url": "/offer/buy/6365433/Le-Clezio-Mondo-Et-Autres-Histoires-Livre.html", "edito": "L oeuvre mondo et autres histoires"},{"label": "Resume j.m.g le clezio dotre histoire de mondo", "url": "/offer/buy/243954/Le-Clezio-Jean-Marie-Gustave-Mondo-Et-Autres-Histoires-Livre.html", "edito": "Mondo et autres histoires texte intégral"},{"label": "Jean marie gustave le clezio mondo et autres histoires folio edition gallimard", "url": "/offer/buy/245753/Le-Clezio-Jean-Marie-Gustave-Mondo-Et-Autres-Histoires-Livre.html", "edito": "Résumé mondo et les autres"},{"label": "Jean-marie gustave mondo le3s personnages", "url": "/offer/buy/483064/Le-Clezio-Jean-Marie-Gustave-Mondo-Livre.html", "edito": "Le livre { mondo et autre histoire },{"label": "J.m.g. le clézio mondo et autres histoires gratuit", "url": "/offer/buy/48918629/Le-Clezio-J-M-G-Mondo-Et-Autres-Histoires-Livre.html", "edito": "Résumé de( mondo et autres histoires)"},{"edito": "Resumé du livre mondo et autre histoires"}]

{"label": "Pack bomb factory mbox2", "url": "/offer/buy/77038735/Digidesign-Mbox-2-Factory-Studio-Alimente-Par-Usb-Pro-Tools-Le-Interfaces-Audio-Digidesign.html", "edito": "Cristal case dea factory"},{"label": "Housse dea factory", "url": "/offer/buy/82237526/urban-factory-protect-sleeve-housse-d-ordinateur-portable-null.html"},{"label": "Dea factory chargeur", "url": "/offer/buy/83830094/dea-factory-blue-light-charge-station-recharheable-battery-accessoire-wii.html"},{"label": "Batterie dea factory+acheter", "url": "/offer/buy/88737680/dea-factory-batterie-rechargeable-pour-wiimote-accessoire-wii.html"},{"label": "Lego super pack technic },{"label": "V smile super pack", "url": "/s/console+vsmile"},{"label": "Super pack delux aggression", "url": "/s/mega+pack"},{"label": "Private super pack", "url": "/offer/buy/49484339/Collectif-Private-Super-Pack-N-3-19-Filles-Tres-Chaudes-Revue.html"},{"label": "Super pack 5", "url": "/offer/buy/15609571/Super-Pack-5-Logiciels-Logiciel.html"},{"label": "Da bird super pack", "url": "/offer/buy/18001077/Cof-Indestructibles-1001-Patte-DVD-Zone-2.html"}]

{"label": "Prince valiant reesition", "url": "/offer/buy/82358997/prince-valiant-david-bergeaud-edition-perseverance-cd-cassettes-mini-disques-laser-disques.html", "edito": "Prince valiant harold foster edition"},{"label": "Prince valiant edition serg", "url": "/s/prince+valiant"},{"label": "Prince valiant {futuropolis},{"label": "Prince valiant cd zucchero", "url": "/offer/buy/49902501/Alannah-Myles-Et-Zucchero-What-Are-We-Waiting-For-Bof-Prince-Valiant-CD-Maxi.html"},{"label": "Collection prince valiant", "url": "/offer/buy/17996301/Collectif-Aventures-Heroiques-Prince-Valiant-N-8---Bande-Dessinee-Livre.html"},{"label": "Prince valiant nes", "url": "/offer/buy/1820066/Prince-Vaillant-Jeu-Nintendo-Nes.html"},{"label": "Prince valiant games", "url": "/offer/buy/2920372/Prince-Valiant-Version-Euro-Noir-Et-Blanc-Jeu-Game-Boy.html"},{"label": "Musique du film prince valiant", "url": "/offer/buy/2990205/Waxman-Franz-Prince-Vaillant-Prince-Valiant-CD-Album.html"},{"label": "Achat dvd prince valiant", "url": "/offer/buy/48523894/Prince-Valliant-DVD-Zone-1.html"},{"label": "Le prince valiant résumé", "url": "/offer/buy/48862018/Graton-Jean-Michel-Vaillant-Tome-30-Le-Prince-Blanc-Livre.html"}]

{"label": "Saints et saintes photos", "url": "/offer/buy/81738765/jean-prieur-saints-et-saintes-de-savoie-livre.html"},{"label": "Chant religieux: saints et saintes de dieu", "url": "/offer/buy/73811318/Saints-Et-Saintes-Quarante-Chants-Volume-1-N-1-Revue.html"},{"label": "Saints et saintes", "url": "/offer/buy/886305/Prieur-Vuillier-Saints-Et-Saintes-De-Savoie-Livre.html"},{"label": "« a travers chants » - volume b ballue", "url": "/s/ballue+jacques"},{"label": "Saints et saintes de dieu", "url": "/offer/buy/49395667/Molin-Pierre-Sainte-Vierge-Marie-Saints-Et-Saintes-De-Dieu-Livre.html"},{"label": "Livres avec les saints et saintes { prieres},{"label": "Saints et images saintes", "url": "/offer/buy/55036257/Image-Pieuse-La-Sainte-Vierge-Et-L-enfant-Jesus-Gerard-David-Art-Catholique-Gravures.html"},{"label": "Vidéo de biographie de saints et saintes", "url": "/offer/buy/46920426/Collection-Vie-Des-Saints-Ste-Bernadette-Soubirous-DVD-Zone-2.html"},{"label": "Vends la clé des chants volume 1", "url": "/offer/buy/48038151/La-Cle-Des-Chants-Vol-1-Im1-Im2-Im3-Livre-De-L-eleve-Cd-Inclus-J-M-Allerme-Ed-Gerard-Billaudot-Partitions-Et-Songbooks-Enfants-Chansons-Musique-Et-Comptines.html"}]

{"label": "Saints et saintes photos", "url": "/offer/buy/81738765/jean-prieur-saints-et-saintes-de-savoie-livre.html"},{"label": "Les pays celtiques", "url": "/offer/buy/70238614/Memoire-Oralite-Culture-Dans-Les-Pays-Celtiques---La-Legende-Arthurienne---Le-Celtisme-Livre.html"},{"label": "Chant religieux: saints et saintes de dieu", "url": "/offer/buy/73811318/Saints-Et-Saintes-Quarante-Chants-Volume-1-N-1-Revue.html"},{"label": "Au fils des jours bore", "url": "/s/henri+bore"},{"label": "Saints et saintes de dieu", "url": "/offer/buy/49395667/Molin-Pierre-Sainte-Vierge-Marie-Saints-Et-Saintes-De-Dieu-Livre.html"},{"label": "Prénoms célèbres", "url": "/offer/buy/534381/Benador-Elia-Les-Prenoms-Celebres-De-La-Litterature-Livre.html"},{"label": "Livres avec les saints et saintes { prieres},{"label": "Les jours et es mois en phonitique englais", "url": "/offer/buy/1084679/Ginesy-Phonetique-Et-Phonologie-De-L-anglais-Livre.html"},{"label": "Serie au fils des jours", "url": "/offer/buy/46355847/Historia-Versailles-Au-Fil-Des-Jours-Hors-Serie-4-Livre.html"},{"label": "Vidéo de biographie de saints et saintes", "url": "/offer/buy/46920426/Collection-Vie-Des-Saints-Ste-Bernadette-Soubirous-DVD-Zone-2.html"}]

{"label": "Saints et saintes photos", "url": "/offer/buy/81738765/jean-prieur-saints-et-saintes-de-savoie-livre.html"},{"label": "Vidéo saints et saintes", "url": "/offer/buy/73811318/Saints-Et-Saintes-Quarante-Chants-Volume-1-N-1-Revue.html"},{"label": "Saints et saintes", "url": "/offer/buy/886305/Prieur-Vuillier-Saints-Et-Saintes-De-Savoie-Livre.html"},{"label": "Saints et saintes de dieu", "url": "/offer/buy/49395667/Molin-Pierre-Sainte-Vierge-Marie-Saints-Et-Saintes-De-Dieu-Livre.html"},{"label": "Livres avec les saints et saintes { prieres},{"label": "Vidéo de biographie de saints et saintes", "url": "/offer/buy/46920426/Collection-Vie-Des-Saints-Ste-Bernadette-Soubirous-DVD-Zone-2.html"}]

{"label": "Sandy stevens - j'ai faim de toi", "url": "/offer/buy/52773476/J-ai-Faim-De-Toi-J-ai-Faim-De-Toi-45-Tours.html", "edito": "Sandy stevens j'ai faim de toi"},{"label": "A vendre sandy stevens", "url": "/offer/buy/10990359/Sandy-J-ai-Faim-De-Toi-45-Tours.html", "edito": "Sandy steven"},{"label": "Sandy j'ai faim de toi maxi 45t pochette", "url": "/offer/buy/30146150/Sandy-J-ai-Faim-De-Toi-Maxi-45-Tours.html", "edito": "Sandy stevens"},{"label": "Sandy - j'ai faim de toi", "url": "/offer/buy/3834528/Sandy-J-ai-Faim-De-Toi-3-Versions-Maxi-45-Tours.html", "edito": "J'ai faim de toi sandy stevens"},{"edito": "Sandy stevens rapidshare"},{"edito": "Photo de sandy stevens"},{"edito": "Cd sandy stevens carrere"},{"edito": "Sandy et steven"},{"edito": "Sandy streeven"},{"edito": "{j'ai faim de toi}]

{"label": "Tri pack cars disney", "url": "/offer/buy/81315442/cars-disney-tri-pack-mia-tia-chick-hicks-jouet.html", "edito": "Cars super sticker"},{"label": "Pack cars disney", "url": "/offer/buy/83829471/bi-pack-cars-disney-snot-rod-et-boost-jouet.html", "edito": "Sticker cars disney mural super geant"},{"label": "Stickers cars disney geant", "url": "/offer/buy/75519946/Coffret-Stickers-Geant-Disney-Cars-Neuf.html", "edito": "Super stickers auto"},{"label": "Cars disney pack 5 voitures", "url": "/offer/buy/87961608/cars-disney-pixar-tri-pack-dinoco-showgirl-avec-flash-macqueen-jouet.html"},{"label": "Lego super pack technic },{"label": "Album panini cars disney", "url": "/offer/buy/59342519/Album-Panini-Cars-Autocollants.html"},{"label": "Pack 6 voitures cars disney", "url": "/s/voitures+cars"},{"label": "Stickers cars disney", "url": "/offer/buy/61726519/Decoration-Murale-Film-Cars-Flash-Mc-Queen-Hudson-Disney-Pas-Stickers-Muraux.html"},{"label": "Pack accessoires ds cars disney", "url": "/nav/Jeux-Video-et-Consoles_Accessoires-Jeux-Video/f1/Nintendo+DS/f2/Skin+-+sticker"},{"label": "Pack accessoire ds lite cars disney", "url": "/nav/Jeux-Video-et-Consoles_Accessoires-Jeux-Video/f1/Nintendo+DS/f2/Transport+-+Rangement"}]
Commentaire de Thierry Leforestier [ 10/févr./10 13:53 ]
en effet, a première vue, ce sont les mêmes cas.




[BIN-653] [Compta] : Modification du rapport "wallet operation detail by completion date" Création: 19/févr./10 14:53  Mise à jour: 26/mars/10 15:08

Etat: Ouvert
Projet: Business Intelligence
Composants: Bug & Improvement
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Claudie Dufresne Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Agathe, Dalila,
Nous souhaitons que soit apportée une modification au rapport "wallet operation detail by completion date"
Il faudrait ajouter une information donc ajouter une colonne pour faire apparaitre le "user id".
Claire qui doit parfois traiter, à notre demande, des transactions en masse a besoin de cette info.
merci à vous
claudie

 Commentaires   
Commentaire de Agathe Remy [ 16/mars/10 14:36 ]
Bonjour Claudie,

Stp, peux-tu me confirmer qu'il s'agit bien d'ajouter le user id correspondant au pseudo déjà affiché dans le rapport, à savoir celui du bénéficiaire de l'opération?

Merci,
Agathe
Commentaire de Claudie Dufresne [ 16/mars/10 15:19 ]
Hello Agathe,

Claire vient de me confirmer qu'il ne s'agit justement pas du user id correspondant au pseudo dans le fichier.
par exemple, pour les paiements vente, il ne s'agit pas du user id du vendeur mais de celui de l'acheteur.

à ta dispo si besoin
merci à toi
claudie
Commentaire de Agathe Remy [ 16/mars/10 16:06 ]
Claudie,

Si je reprends ton exemple de paiement des ventes, une même opération pouvant correspondre au paiement de plusieurs transactions donc plusieurs acheteurs. Cela voudrait donc dire que pour chaque acheteur la même ligne opération sera dupliquée?!
De plus, peux-tu me préciser quels sont les autres cas possibles?

Merci,
Agathe
Commentaire de Julien Girardet [ 26/mars/10 14:58 ]
Bonjour,

Voici le CR du point Finance/Backoffice du 25/03/2010 :

Existant :
Dans le cadre de la régularisation Compta/BackOffice, le BackOffice doit effectuer des opérations de « remboursement à tort » acheteurs.
Pour ce faire, la Compta transmet au BackOffice le listing des opérations de type « crédit BO » avec comme cause « Paiement vente » à l'aide du rapport « wallet operation detail by completion date ».
Ces opérations correspondent à des paiements vendeurs effectuées manuellement par le BackOffice. (Exemple : Paiement vendeur sur une transaction avec réclamation de type PVZA). Chaque opération « Crédit BO - Paiement vente » correspond à une seule transaction.
A partir de l'identifiant article rattaché à l'opération, le BackOffice détermine si l'acheteur à été remboursé à tort et, le cas échéant, crée une opération de débit « remboursement à tort ».
Le BackOffice automatise ces opérations de remboursement à tort à l'aide d'un lien qui prend comme paramètre l'identifiant de l'acheteur. Or actuellement, seul l'identifiant article est présent dans le rapport « wallet operation detail by completion date ».

Besoin :
Connaître l'identifiant acheteur des transactions (articles) ayant une opération finalisée de type « crédit BO » avec comme cause « Paiement vente »
L'ajout de l'identifiant acheteur facilitera l'analyse de transaction par le BackOffice (accès direct sur le compte de l'acheteur pour déterminer si il y a eu un remboursement à tort ou non) et la création de l'opération de remboursement acheteur (paramètre du lien).

Proposition :
Développer un nouveau rapport BI du même type que le rapport « wallet operation detail by completion date » mais uniquement pour les opérations de type « crédit BO » avec comme cause « Paiement vente » et en ajoutant l'identifiant acheteur (buyer account id) de la transaction, ainsi qu'un lien BackOffice vers le compte acheteur. Attention : ce lien ne correspond pas à l'automatisation des remboursements à tort mais uniquement au compte BackOffice acheteur.

N'hésitez pas à me faire part de vos retours.

Si s'est OK pour tout le monde, nous pourrons rédiger les specs, puis après validation, nous développerons le rapport.

Merci,

Julien.
Commentaire de Claire Durand [ 26/mars/10 15:08 ]
c'est parfait pour moi, merci




[cob] META-TACHE Fermeture LeProgrès (APP-28357)

[APP-28365] Envoyer l'e-mail aux membres de LeProgrès pour les prévenir de la fermeture / redirection vers price. Création: 18/févr./10 18:14  Mise à jour: 15/avr./10 17:12  Echéance: 12/mars/10 00:00  Résolue: 22/mars/10 10:26

Etat: Fermé
Projet: Application PriceMinister
Composants: Cobrandings
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 67.0.0 (CTN-Q)

Type: Sous-tâche Priorité: Majeur
Rapporteur: Fabrice Feugas Attribution: Jonathan Gorges
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***

 Commentaires   
Commentaire de Jonathan Gorges [ 12/mars/10 16:24 ]
Hello,

L'e-mail a bien été envoyé comme convenu à l'ensemble des membre de LeProgrès.

Merci à l'équipe BI pour l'export des adresses et merci également à Damien Gilloz pour avoir passé du temps sur l'envoi de ce mail.

Pour info, nous avons envoyé le message classique de coupure de cob, via Gmail en utilisant l'adresse nepasrepondre@priceminister.com.

Après suppression des doublons, environ 420 adresses étaient concernées par cette coupure du cob.

Bon week-end.

Jonathan




[BIN-664] [TFV] : Taux de transfo vendeurs Création: 24/mars/10 10:36  Mise à jour: 26/mai/10 18:32  Résolue: 09/avr./10 18:11

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Audrey Angleys Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel DATAS_JIRA_BIN_664_2010.xls     Text File requête_Jira_BIN-664.sql    
Pays:
FRA - France

 Description   
Hello

Comme discuté hier, je cherche à connaitre les taux de transfo:
1) des INA en vendeurs
2) des acheteurs en vendeurs

Mon objectif est de voir comment évolue notre capacité à transformer nos vendeurs (en acquisition pure/en migration de profil) et de déterminer si ces taux se dégradent dans le temps.

On pourrait regarder le nombre d'INA/d'acheteurs au mois M et regarder à M+3, combien de personnes de ces populations sont devenus vendeurs.
Et ensuite comparer ce chiffre à celui de la même époque l'année précédente.
Par ex: dans la population des INA/acheteurs du mois de janvier 2010, combien sont devenus vendeurs aujourd'hui?
à comparer à: dans la population des INA/acheteurs du mois de janvier 2009, combien étaient vendeurs au 24 mars?

A votre dispo si ce n'est pas clair.

Merci d'avance pour votre aide!

Audrey



 Commentaires   
Commentaire de Audrey Angleys [ 06/avr./10 15:51 ]
Salut Agathe,

As-tu pu réfléchir à cette demande?
J'aurai souhaité agréger ces chiffres dans le cadre de ma présentation de la semaine prochaine (sur la baisse du recrutement des vendeurs).

A ta dispo pour en discuter de vive voix

Merci d'avance
Audrey
Commentaire de Cyril Tanneau [ 09/avr./10 18:11 ]
Salut Audrey,

tu trouveras dans le dossier ci-dessous le fichier JIRA_664_09042010.xls faisant suite à ta demande.

V:\Reporting\BusinessIntelligence\01 - Etudes ponctuelles\2010-04\Jira_BIN-664_Transfo_vendeurs

Les règles fonctionnelles du comptage sont indiquées dans l'onglet ReadMe.

Peux-tu nous valider ce document?

merci,

Cyril
Commentaire de Audrey Angleys [ 09/avr./10 18:23 ]
Salut Cyril,

D'après le doc en PJ, cela semble correspondre à ma demande, merci.
En revanche, je n'ai pas le même V:\ que vous, est-ce que tu pourrais le mettre dans T:\ plutôt?

Merci beaucoup

Audrey
Commentaire de Cyril Tanneau [ 09/avr./10 18:28 ]
Audrey,

les comptages sont finalement disponibles dans le dossier ci-dessous, en effet tu n'as accès à celui que j'ai indiqué dans le post précédent

T:\BI\01 - Demandes ponctuelles\02 - Etudes Marketing\Jira_BIN-664_Audrey_Transfo_vendeurs

Merci,

Cyril
Commentaire de Cyril Tanneau [ 13/avr./10 11:39 ]
Salut Audrey,

As-tu eu le temps de regarder les comptages fournis dans le cadre de cette étude? En ce cas peux-tu valider la demande si cela te convient?

Merci pour ton retour,

bonne journée,

Cyril
Commentaire de Audrey Angleys [ 13/avr./10 11:56 ]
Salut Cyril,

J'étais justement en train de regarder et cela nous semble assez important comme chiffre (voire bizarre).
Du coup on regarde de plus près et je reviens vers toi.

Merci

Audrey
Commentaire de Agathe Remy [ 26/mai/10 18:32 ]
Je ferme cette demande en raison de la livraison de la nouvelle version du rapport New sellers by first advert date du 20/05/2010.

Agathe




[IMP-5694] FP Pseudo mstore - mentions !!! Garantie Music Store 3 ans !!! - !!! Garantie "Satisfait ou remboursé" 30 jours !!! dans les commentaires Création: 31/mars/10 11:16  Mise à jour: 23/avr./10 10:32  Résolue: 23/avr./10 10:32

Etat: Résolu
Projet: Paramétrage - Import
Composants: Projet import
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Anthony Briou Attribution: Frédéric Nahum
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: mstore
Séparateur: N/A
Type de traitement:
Mise à jour/création annonces avec mise à jour/création produits

 Description   
les fiches importées par mstore ont les mentions !!! Garantie Music Store 3 ans !!! - !!! Garantie "Satisfait ou remboursé" 30 jours !!! dans les commentaires, ce qui pose des problème, les types "instruments" et "sono & matériel de studio" étant en fonctionnement "fiche public".

CF :

http://bo.priceminister.com/referential_back?action=notelist&popup=false&productid=92263145

http://bo.priceminister.com/referential_back?action=notelist&popup=false&productid=92264001

http://bo.priceminister.com/referential_back?action=notelist&popup=false&productid=92263817

http://bo.priceminister.com/referential_back?action=notelist&popup=false&productid=98701593




 Commentaires   
Commentaire de Jérome Marianne [ 16/avr./10 16:00 ]
Pour pouvoir mettre à jour toutes ses fiches produits il faut une extraction BI de son stock avec les ID produits et le descriptif entre autre, à rajouter en pièce jointe au JIRA.

A demander à Dorian ou à Xavier Fabregat s'il sait le faire.
Commentaire de Jérome Marianne [ 16/avr./10 16:02 ]
Erratum: En fait le commercial qui gère ce pro est Jeremy Pallot et non pas Dorian.
Commentaire de Fotigui Tangara [ 20/avr./10 14:18 ]
J'ai mis Gaël et Jérémy Pallot en observateur du Jira. Je pense plutôt que c'est à Jérémy Pallot de faire l'extraction de stock et le mettre en copie de ce Jira, car il est le commercial en charge du partenaire mstore (voir bo), donc mieux placé.

Commentaire de Frédéric Nahum [ 23/avr./10 10:32 ]
j'ai corrigé le format d'import de facon a supprimer cette mention au prochain import,
Pour les produit restant il faudrait demander cela à l'équipe catalogue




[EXP-5082] Mise en place technique du partenariat LCL - Affectation de coupons perso aux Adhérents LCL Création: 08/avr./10 17:58  Mise à jour: 10/août/10 10:38  Résolue: 10/août/10 10:38

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Jonathan Gorges Attribution: Jérémie Bennejean
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft PowerPoint PM - Procédure PriceMinister.ppt    
Pays:
FRA - France

 Description   
Bonjour,

Voici comme convenu la demande de mise en place technique du partenariat LCL / PriceMinister. Petits rappels :

** Contexte :
- Opportunité de partenariat entre PriceMinister et le LCL.
- Le programme de fidélisation LCL permet aux adhérents de gagner des points par leur comportement bancaire et de les échanger contre des codes d'achat.
- Nous voulons que PM soit partenaire et que les adhérents LCL puisse convertir leurs points en code de réduction PriceMinister.
- Nous devront donc utiliser le Webservice afin de générer des coupons personnalisés et les affecter à ces différents internautes.

** Objectifs business :
- Recrutement de nouveaux acheteurs. Générer du business incrémental via le LCL.
- Ce partenariat est également une porte d'entrée dans la domaine bancaire avec de futurs partenariats possibles (si celui-ci fonctionne bien)

** Objectifs "fonctionnel" :
- Livrer les coupons aux internautes de manière rapide, fluide (et efficiente de notre côté).
- Possibilité d'utiliser le coupon immédiatement sur le site PM par l'internaute, sans formalités supplémentaires par rapport à un visiteur ou client standard.

** Contraintes :
- Une même adresse email dans la base PriceMinister peut être affectée à plusieurs comptes différents.
- L'adhérent du LCL peut être déjà client PM, ou prospect.

** Autres informations :
- Un seul coupon sera utilisable pour le moment : coupon de 10¿ sans minimum, valable sur tout achat (pas nécessairement sur du premier achat).

** Process à mettre en place / demande technique pour Eric :
Isilis nous fournira quotidiennement un fichier CSV sur notre FTP avec la liste de tous les internautes ayant converti leurs points en coupon PriceMinister.
 - Le fichier contiendra uniquement les adresses email des adhérents ayant choisi les coupons PriceMinister.
 - Comme vu ensemble, nous affecterons les coupons de la manière suivante :
    a. Si l'adresse email fournie par Isilis est identifiée chez nous sur 1 compte -> nous affecterons ce coupon sur ce même compte.
    b. Si l'adresse email fournie par Isilis est identifiée chez nous sur plusieurs comptes -> nous affecterons ce coupon sur le dernier compte actif.
    c. Si l'adresse email fournie par Isilis n'est pas connue dans notre base -> nous créons un compte « contact » en affectant le coupon sur l'adresse email fournie.
        Le coupon sera directement utilisable par l'internaute une fois le compte PriceMinister créé avec la même adresse email.
 
- En plus de cela, vous générerez automatiquement les dates de création des comptes existants afin de pouvoir affecter les coupons sur ces mêmes comptes.
- Pour les comptes existants, vous générerez également automatiquement les login associés aux adresses emails pour affecter les coupons aux bons comptes.

Enfin, nous préciserons bien à l'internaute dans l'email automatique envoyé, quelle est la marche à suivre pour utiliser le coupon (quel compte, login, adresse...)

Voilà, j'espère ne rien avoir oublié. N'hésitez pas à compléter cette demande si certains points ne sont pas évoqués. Je mets tout le monde dans la boucle (les participants à la micro RU) afin de faciliter la mise en place de ce projet.

Eric, sauf erreur de ma part, ce projet devrait faire parti de ta liste de projets prioritaires. Pourrais-tu ainsi me communiquer stp, même très vaguement, une date possible de livraison ? Il s'agit juste pour moi d'informer le partenaire.

Merci d'avance pour tout.

Jonathan



 Commentaires   
Commentaire de Eric Vannier [ 13/avr./10 09:32 ]
Pour le cas ou le contact n'existe pas , il faut créer un code tracking qui sera utilisé par l'import de contact, ce qui va nous permettre par la suite de connaitre les nouveaux contacts acquis par ce biais. Celui-ci devra exister sinon la création des coupons ne sera pas possible.

Merci de me le communiquer dans ce jira.
Commentaire de Jonathan Gorges [ 14/avr./10 10:43 ]
Hello Eric,
Merci pour ce retour. Cependant, je ne comprends pas très bien l'intérêt de ce code de tracking.

Pourrait-on à la place rajouter une colonne dans le fichier CSV qui s'intitulerait "Client ?" avec :
Si prospect (compte contact) = 0
Si client (compte PriceMinister) = 1

De cette manière, tu pourras facilement déterminer s'il s'agit d'un compte contact ou d'un compte client.

Est-ce possible ?

Merci d'avance pour ton retour.

Jonathan.
Commentaire de Jonathan Gorges [ 15/avr./10 17:50 ]
Vous trouverez ci-joint la procédure de mise en place technique côté Isilis.

De mon côté, tout me semble bon (excepté qq petits détails, peu sensibles).

Pourriez-vous valider cette procédure de votre côté svp ou y apporter des modifications ?

Merci d'avance pour vos retours.

Jonathan.
Commentaire de Jonathan Gorges [ 20/avr./10 12:14 ]
Hello,

Voici comme convenu le First Tracking à affecter aux comptes contact lors des imports : 2297741
(LCL_new_contacts)

A votre dispo.

Jon
Commentaire de Jérémie Bennejean [ 10/août/10 10:38 ]
Done.




Quamedia : Vérification/Mise à jour du tag + ajouts nouveaux codes de tracking (APP-28836)

[APP-28985] Vérification du code / Adaptation Création: 01/avr./10 12:15  Mise à jour: 12/avr./10 09:50  Résolue: 12/avr./10 09:00

Etat: Fermé
Projet: Application PriceMinister
Composants: Tracking
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 66.0.1

Type: Sous-tâche Priorité: Majeur
Rapporteur: Carole Boucheny Attribution: Carole Boucheny
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** CHASSE ***

 Description   
Il y a 2 soucis avec le code fourni pour Quamedia :
_ premièrement, il y a du xml dans ce code et il peut être mal interprété par IG car lui-même est en xml. Olga a déjà rencontré des cas où ça faisait planter ce qu'il y a après. Donc faut-il bien supprimer : /*<![CDATA[*/ ?
_ deuxièmement, les info « Type de commande »,« Type de paiement » et « Nom du produit » ne remontent pas. Je ne vois pas pourquoi, ça doit surement venir du js appelé. Est-ce qu'il vaut mieux supprimer cet appel et mettre nos variables comme pour les autres tag ?


 Commentaires   
Commentaire de Alexandre Garnier [ 01/avr./10 12:24 ]
1. On peut supprimer les CDATA dans ce cas (c'ets dommage mais on a pas le choix)
2. Je ne vois pas ce que peut être "Type de commande". Je ne suis pas sûr qu'on ai le type de paiement, ni qu'on puisse avoir le nom du produit (on a des articles dans le panier), qui au passage est optionnel.

Mais sinon, on pourrait pas envoyer tout ça avec des flux BI plutôt que de multiplier les tags à l'infini ?
Commentaire de Alexandre Garnier [ 01/avr./10 15:36 ]
Faire un copier/coller des tags EULERIAN existants (/promotions/Promotions/FR/Affiliation/Emails abandonnistes/*)

En faisant attention de bien appeler le ea.js externe et de mettre le bon commentaire "Eulerian Analytics - priceminister-fr / scartamount" autour du code.

Ensuite si les tags existants ne comporte pas les informations demandées, c'est qu'elles ne sont pas disponibles :
* Type de commande : qu'est-ce que ça veut dire ?
* Type de paiement : on a pas
* Nom du produit : on a pas
Commentaire de Alexandre Garnier [ 01/avr./10 15:37 ]
[CAJ2010Q1CTN]
Commentaire de Christophe Garcia [ 09/avr./10 18:03 ]
MDPLVC




[APP-29300] Implémentation des tags TradeDoubler Affiliation sur PriceMinister UK et ES Création: 22/avr./10 18:18  Mise à jour: 09/août/10 15:28  Résolue: 15/juin/10 11:45

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 70.0.2.1

Type: Amélioration Priorité: Majeur
Rapporteur: Thomas Springett Attribution: Ariane Baldinger
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: PDF File implementation_manual_adv_080418[1].pdf     PDF File productfeeds_manual_nov_2003.pdf     JPEG File secure payment.jpg    
Liens des demandes:
Similaire
similaire à APP-30606 Problème de tracking avec le pixel de... Fermé
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-29302 validation technique et fonctionnelle... Sous-tâche Fermé Damien Dorizy  
APP-29636 [ES] implémentation du nouveau tag tr... Sous-tâche Fermé Rocio Perez-Garcia  
APP-29657 [ES] implémentation du nouveau tag tr... Sous-tâche Fermé Rocio Perez-Garcia  
APP-29658 [UK] implémentation du nouveau tag tr... Sous-tâche Fermé Rémi Virlouvet  
APP-29659 [UK] implémentation du nouveau tag tr... Sous-tâche Fermé Rémi Virlouvet  
Pays:
GBR - Royaume Uni, ESP - Espagne
Projets PM: *** A PLANIFIER ***

 Description   
Bonjour,

Veillez trouver ici les aspects techniques et fonctionnels pour l'intégration du TradeDoubler sur lES et UK.


Elements à tracker
les achats en différenciant les 1ers achats des autres achats
ainsi que les 1ères mises en vente

Il faut aussi tracker le VA et CA généré par le plateforme.

 Commentaires   
Commentaire de Ariane Baldinger [ 27/avr./10 11:06 ]
Salut,

il y a déjà des tags Tradedoubler pour tracker tous les achats, en ES et UK. Toujours actifs.

En ES on a ce tag :
<!-- DEBUT du code Tradedoubler-->
<img src="https://tracker.tradedoubler.com/report?organization=934869&event=16084&orderNumber=$purchase.purchaseId&orderValue=$purchase.SumItemPriceNumber&currency=EUR" width="1" height="1">
<!-- FIN du code Tradedoubler -->

avec les codes de tracking suivant : 1304040, 1304041, 1304042, 1304043, 1304044, 1304045, 1304046, 1508040, 1508041

et en UK :
<!-- DEBUT du code Tradedoubler-->
<img src="https://tbs.tradedoubler.com/report?organization=1348472&event=154392&orderNumber=$purchase.purchaseId&orderValue=$purchase.SumItemPriceNumber&currency=GBP" width="1" height="1">
<!-- FIN du code Tradedoubler -->

avec les codes de tracking suivant : 1366340, 1366341, 1366440, 1366441, 1372141,1380141,1384142,1384143


Devrons-nous les supprimer ?
Commentaire de Benjamin Guerville [ 27/avr./10 15:36 ]
je demande à TD et reviens vers vous
merci
bg
Commentaire de Ariane Baldinger [ 03/mai/10 09:39 ]
mail de Benjamin le 30/04 :
"Pour info, il est fortement conseillé de remplacer les anciens tags par les nouveaux"
Commentaire de Ariane Baldinger [ 20/mai/10 17:19 ]
Thomas,
1. Quelles infos doit-on passer dans le tag qui tracke les 1ères mises en vente ? et dans quels paramètres ?
2. Peux-tu également indiquer les codes de tracking (s'il y en a) que nous devons paramétrer pour chacun des tags, et pour chaque pays ? (les codes de tracking utilisés actuellement sont indiqués + haut dans le jira)

Merci!

Commentaire de Thomas Springett [ 25/mai/10 12:00 ]
Bonjour,

Pour le premier mise en vente l'information que nous devons remonter est le user ID (Même que CJ pour le UK).

Tracking : a venir.



Thanks,
Commentaire de Thomas Springett [ 25/mai/10 14:52 ]
Tracking ES:

Tracking code: TDclassic:
1710040

Group:
TradeDoubler ES:
http://bo.priceminister.es/tracking_back?action=ustgroupsearch&name=&siteid=&start_date=&end_date=26%2F05%2F2010&number_rows=100&x=61&y=12
Commentaire de Thomas Springett [ 25/mai/10 14:56 ]
Tracking UK:

Tracking code: TDclassic:
1408140

Group:
TradeDoubler UK:
http://bo.priceminister.co.uk/tracking_back?action=ustgroupsearch&name=&siteid=&start_date=&end_date=25%2F05%2F2010&number_rows=100&x=32&y=3
Commentaire de Ariane Baldinger [ 26/mai/10 14:03 ]
mail de Bruno de Tradedoubler concernant les identifiants à utiliser :

"pour l'Espagne :
- organization=934869
- event=16084 (achat)
- event= 200384 (first listing)


Et pour le UK :
- organization=934869
- event=16084 (achat)
- event= 200384 (first listing)

Explication : afin de simplifier le management et le tracking, nous utiliserons la même organisation pour tous les programmes à venir. Si un de vos partenaire utilise un autre tracking et que vous deviez le garder, merci de me donner des détails afin que je puisse étudier rapidement si une alternative est possible.
"
Commentaire de Thomas Springett [ 27/mai/10 09:45 ]
Pour les tracking Un suffit pout l'achat et mise en vente c'est uniquement les tags qui sont diiferent.
Commentaire de Thomas Springett [ 28/mai/10 12:31 ]
Bonjour,

Pour le tracking de premier mise en vent il serait plus intéressant de tager le page "activation de boutique" que le soumission d'annonce. environ 25% de vendeur ne franchise pas l'étape activation de compte et nous voulons payer uniquement pour les annonce visible.

Si c'est un travaille trop important a réaliser avant le 03/06/2010 nous pourrions le faire a posteriori.

Thomas
Commentaire de Fabrice Feugas [ 28/mai/10 14:25 ]
Hello,

Je pense que le problème que tu auras si tu tagues l'ouverture de boutique, c'est que à moins qu'elle ne se fasse dans la même visite tu risque de perdre le tracking de tradedoubler et donc de ne pas faire remonter le tag.

C'est pas bête comme notion de se baser sur l'ouverture de boutique mais il y a des failles je pense...

Au pire ce que tu peux faire, c'est un listing via BI des 1ères mises en vente avec annonce visible ayant pour tracking tradedoubler et comparer via excel avec les données remontées à tradedoubler.

En faisant le différentiel tu obtiendras toutes les annonces non visibles.

Mais habituellement on rémunère toujours sur la première MeV visible ou non je crois. Ce qui est logique qq part, l'affilié a fait son boulot de nous apporter une nouvelle MeV et il a rempli sa part du contrat. Après à nous d'être bon pour faire ouvrir la boutique.
Commentaire de Thomas Springett [ 28/mai/10 15:34 ]
Hi,

Il y du logique dans les deux sens, En france nous sommes à 8% des mise en vente qui transform en boutique ouverte, pour le UK et ES cest 25%.--

 activé UK 9441 - ES 11841
 non activé UK 2961 - ES 4520

Par contre le risque de perte de tracking est très important donc il est mieux de rester sur le MeV.
Commentaire de Thomas Springett [ 28/mai/10 15:57 ]
Pardon, petit precision:qui NE transform PAS en boutique ouverte,
Commentaire de Ariane Baldinger [ 31/mai/10 16:06 ]
Au final que fait-on ?
Habituellement on tracke l'évènement 'SELLER_ACCOUNT_ACTIVATION" plutôt que 'FIRST_ADVERT'
Commentaire de Thomas Springett [ 31/mai/10 16:11 ]
'SELLER_ACCOUNT_ACTIVATION
sinon comme disait Fabrice, on risk de ne pas payée pas mal des nouveau vendeur.
Commentaire de Thomas Springett [ 31/mai/10 16:25 ]
Sorry::::

'FIRST_ADVERT'
Commentaire de Fabrice Feugas [ 31/mai/10 16:47 ]
@Ariane, habituellement on taggue les 1ères mises en vente sur l'ouverture de la boutique ???!

Et s'il y a eu plusieurs mises en ventes avant l'ouverture de la botique, on fait remonter cette info dans le tag ?

Comment ça fonctionne ?
Commentaire de Ariane Baldinger [ 07/juin/10 09:43 ]
param fait pour le dump du 08/06 (cf. sous-tâches) (ES et UK)
Commentaire de Fabrice Feugas [ 14/juin/10 18:30 ]
JIRA fils re-ouvert :

"Christina Recoules - 14/juin/10 18:16
Tag tradedoubler non présent sur la page secure payment sur uk "
Commentaire de Rémi Virlouvet [ 15/juin/10 11:45 ]
ok sur buy en uk (dans hidden 1)




[IMP-5979] sport-access : analyse fichier en trop d'erreur Création: 03/mai/10 17:10  Mise à jour: 03/mai/10 17:51  Résolue: 03/mai/10 17:51

Etat: Résolu
Projet: Paramétrage - Import
Composants: Support monitoring
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Jérome Marianne Attribution: Jérome Marianne
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: sport-access
Séparateur: N/A
Type de traitement:
N/A

 Commentaires   
Commentaire de Jérome Marianne [ 03/mai/10 17:15 ]
Mail du pro en complément:

Bonjour,

Je viens d'envoyer un fichier de stock par le biais de mon compte FTP.
Mais sur chaque ligne j'ai ce message d'erreur : Cette valeur d'attribut "PM08284347" n'est pas permis pour ce type de produit
Pouvez-vous m'indiquer quel est le problème ?

Merci d'avance.
Vincent (sport-access)
Commentaire de Jérome Marianne [ 03/mai/10 17:51 ]
Le problème venait d'un bug dans la valeur "type de produit" de la valeur chaussure du mapping.
La clé valeur ne renvoyait pas sur la bonne valeur "chaussure".

Après correction et retraitement le fichier passe à 100%




[IMP-6719] changer commentaire annonce FAIR AND FAST Création: 05/août/10 16:46  Mise à jour: 20/août/10 15:54  Résolue: 20/août/10 15:54

Etat: Résolu
Projet: Paramétrage - Import
Composants: Demande commerciale
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Julien Buhagiar Attribution: Fotigui Tangara
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Zip Archive extraction stock FairandFast 13.08.10.csv.zip    
Pays:
FRA - France
Login: Fairandfast1
Séparateur: N/A
Type de traitement:
N/A

 Description   
Suite au IMP-6664

Mettre par défaut le commentaire annonces suivant:
ETAT DU LIVRE + Les livres sont expédiés du Royaume-Uni par avion en courrier prioritaire du lundi au vendredi, emballés dans du papier à bulles et expédiés dans des enveloppes rembourrées et devraient arriver dans les 8 jours ouvrables.

 Commentaires   
Commentaire de Fotigui Tangara [ 06/août/10 11:57 ]
Peux-tu nous fournir une extraction de stock du PRO ?
Commentaire de Fotigui Tangara [ 10/août/10 11:24 ]
Tu peux avoir l'extraction de stock du PRO depuis l'outil BI mis à disposition de l'équipe commerciale, renseigne toi auprès de Gaël ou Isabelle, ou Anne ou l'équipe BI... C'est beaucoup plus rapide de passer par cet outil interne (BI). D'habitude, nous ne demandons pas de fichier d'extraction de stock à Sellermania ni à Neteven car les fiches produits sont dans notre base....
Commentaire de Julien Buhagiar [ 13/août/10 15:12 ]
Extraction stock dans ton public (Fotigui)

En fait je pense que ma demande va être difficile. Chaque début de ses commentaires annonces est différente. Difficile de rajouter un commentaire automatique, en gardant en plus le début du commentaire du pro qui varie sur chaque ligne. A voir...
Commentaire de Fotigui Tangara [ 17/août/10 15:13 ]
Il est envisageable de corriger 30 000 annonces sur 35 000 suivant ton commentaire initial.

"ETAT DU LIVRE + Les livres sont expédiés du Royaume-Uni par avion en courrier prioritaire du lundi au vendredi, emballés dans du papier à bulles et expédiés dans des enveloppes rembourrées et devraient arriver dans les 8 jours ouvrables.'"

Commentaire de Fotigui Tangara [ 20/août/10 15:07 ]
Fichier en cours de traitement pour la modification des commentaires d'annonces...
Commentaire de Fotigui Tangara [ 20/août/10 15:54 ]
Demande traitée.




[IMP-6867] Demande de relance de fichier de commande (par flux FTP) Création: 30/août/10 14:32  Mise à jour: 30/août/10 14:47  Résolue: 30/août/10 14:47

Etat: Résolu
Projet: Paramétrage - Import
Composants: Support entrant
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Daniel Pintamalli Attribution: Daniel Pintamalli
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: PhoneAnPhone
Séparateur: N/A
Type de traitement:
N/A

 Description   
De : Mehdi [mailto:mehdi@phoneandphone.com]
Envoyé : vendredi 27 août 2010 15:20
À : support.pro@priceminister.com; julien.buhagian@priceminister.com
Cc : 'Nathalie Monchery'
Objet : fichier 24/08/10 / 90301559

Bonjour,

Merci de bien vouloir relancer la commande 90301559 qui ne s'est pas exporte dans notre base.

Merci d'avance

Cdt.


 Commentaires   
Commentaire de Daniel Pintamalli [ 30/août/10 14:47 ]
De : Support Pro [mailto:support.pro@priceminister.com]
Envoyé : lundi 30 août 2010 14:48
À : 'Mehdi'
Cc : 'Nathalie Monchery'; 'julien.buhagian@priceminister.com'
Objet : RE: fichier 24/08/10 / 90301559

Bonjour,

Comme ce panier a été validé manuellement, le système ne génère pas de fichier par le biais de FTP. Malheureusement, on ne peut pas fournir ce fichier.


Cordialement,

Daniel Pintamalli




[APP-7661] Blocage au niveau de la soumission en front de fiches produits bières Création: 27/févr./06 15:02  Mise à jour: 25/juin/07 18:35  Résolue: 28/févr./06 15:40

Etat: Fermé
Projet: Application PriceMinister
Composants: Mise en vente
Affecte la/les version(s): 8.1.1
Version(s) corrigée(s): 8.1.1b

Type: Bogue Priorité: Critique
Rapporteur: Ludovic Piot Attribution: Geneviève Beaujard
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Site: Prod

 Description   
Bonjour,

Visiblement il y a un problème lors de la soumission de fiche produit de bières, lorsqu'on souhaite créer une annonce pour vendre des bières de type rousse ou ambrée, on sélectionne cet attribut, le processus de création de la fiche et de l'annonce se passe bien, puis lors de la dernière validation, ça bloque.... Voici le message qui apparait: "Cette valeur d'attribut "PM08631260" n'est pas permis pour ce type de produit ou pour ce support."

Si, on fait de même en sélectionnant "Blonde" ou "Blanche", ça marche correctement. Mais que se passe t'il? Il y a tjs un marché pour les "Rousses" et les "Ambrées", c'est quoi cette ségrégation....? :-)

Merci de regarder cela, que je puisse revenir vers mon partenaire qui soumet ce type de produits.

Très cordialement.

Ludo

 Commentaires   
Commentaire de Fabien Farache [ 27/févr./06 19:13 ]
Il y a un problème que je n'arrive pas résoudre.
L'appli répond que la valeur n'est pas mappé or lorsqu'on regarde la valeur à laquelle correspond la clé indiquée on peut s'appercevoir qu'elle est bien mappée pour ce type de produit et ce support. Si on regarde comment sont mappées les autres valeurs correspondant à l'attribut on peut voir qu'il n'y a pas de différence.

Je suis allé voir dans les logs et il semblerait qu'il y ait un problème au niveau du $form.goBack()

Quelqu'un peut il m'aider svp


extrait du log :
>>> GET http://preview.priceminister.com/submit?action=submitcomplete&advertid=42200398&appellation=164293&categoryref=164483&compproductid=18709159&conditionnement=168324&contenance=168319&designation=TESTPM+Bi%E8re&prix=500.0&productid=18709158&qualite=EC&quantite=1&stage=200&submitstage=true&typeProduit=163001&x=70&y=13
2006-02-27 19:10:13,732 WARN [-Processor15] FAF-pm - BEGIN_AUDIT work() OLD MODE
2006-02-27 19:10:13,732 INFO [-Processor15] FAF-pm - Updating product 18709158
2006-02-27 19:10:13,807 WARN [-Processor15] FAF-pm - END_AUDIT work()
2006-02-27 19:10:14,499 WARN [-Processor15] FAF-pm - org.apache.velocity.runtime.exception.ReferenceException: reference : template = PMVelocity - Submit form assembly[165667] [line 217,column 16] : $form.goBack() is not a valid reference.
2006-02-27 19:10:14,503 INFO [-Processor15] FAF-pm - <<< [924 ms] GET http://preview.priceminister.com/submit?action=submitcomplete&advertid=42200398&appellation=164293&categoryref=164483&compproductid=18709159&conditionnement=168324&contenance=168319&designation=TESTPM+Bi%E8re&prix=500.0&productid=18709158&qualite=EC&quantite=1&stage=200&submitstage=true&typeProduit=163001&x=70&y=13
Commentaire de Geneviève Beaujard [ 28/févr./06 15:40 ]
J'aime beaucoup la formulation de Ludovic.
En fait c'etait un probleme de conf:
la categorie 164293 (Ambrée ou Rousse) du formulaire produit n'avait pas le bon attribut.
Fabien a corrigé, c'est OK maintenant.
Commentaire de Lydia Dali [ 01/mars/06 10:25 ]
ok, testé en prod.




[EXP-1537] Problème de génération des pages statiques sur PHAETON pour le BRAND bo.priceminister.com.jmh Création: 17/mars/06 09:53  Mise à jour: 25/juin/07 18:57  Résolue: 17/mars/06 14:17

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Sébastien Tournay Attribution: Ranto Andriambololona
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Sur PHAETON, nous avons les erreurs ci-dessous. Je pense que c'est lié au fait que nous avons renomé le brand bo.priceminister.com.jmh en bo.jmh.lan. A corriger donc ASAP.

également, il me semblait que l'on devait supprimer la mention 'site de test' en accédant à bo.jmh.lan. Cela devait être livré avec la V812. Visiblement cela n'est toujours pas réglé. Il faut rouvrir le JIRA en question et faire le point avec Christophe.

bo.priceminister.com.jmh:../Pseudo-static-pages-script.sh: line 36: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/accueil.newtemp: No such file or directory

Looking up bo.priceminister.com.jmh
bo.priceminister.com.jmh
Unable to locate remote host bo.priceminister.com.jmh.
Alert!: Unable to connect to remote host.

lynx: Can't access startfile http://bo.priceminister.com.jmh/home?page=10&static=true
grep: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/accueil.newtemp: No such file or directory
grep: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/accueil.newtemp: No such file or directory
mv: cannot stat `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/accueil.newtemp': No such file or directory
../Pseudo-static-pages-script.sh: line 36: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/livres-bd.newtemp: No such file or directory

Looking up bo.priceminister.com.jmh
bo.priceminister.com.jmh
Unable to locate remote host bo.priceminister.com.jmh.
Alert!: Unable to connect to remote host.

lynx: Can't access startfile http://bo.priceminister.com.jmh/navigation/default/category/root_books?static=true
grep: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/livres-bd.newtemp: No such file or directory
grep: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/livres-bd.newtemp: No such file or directory
mv: cannot stat `/data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/livres-bd.newtemp': No such file or directory
../Pseudo-static-pages-script.sh: line 36: /data/chrootapache/usr/local/apache/htdocs/pmweb/virtualhost-priceminister/musique-cd.newtemp: No such file or directory

Looking up bo.priceminister.com.jmh
bo.priceminister.com.jmh
Unable to locate remote host bo.priceminister.com.jmh.
Alert!: Unable to connect to remote host.


 Commentaires   
Commentaire de Ranto Andriambololona [ 17/mars/06 14:06 ]
J'ai corrigé le soucis en suprimmant les entrées http://bo.priceminister.com.jmh sur Phaeton
Je reprends le projet migration de bo.jmh.lan dans un autre JIRA

[adminpm@phaeton pseudo-static-pages]$ ./Pseudo-static-pages-script.sh
Starting with sleeptime = 0
www.radindesbois.com:................ done
www.priceminister.com:................ done
www.croix-rouge.priceminister.com:................ done
virginmega.priceminister.com:................ done
tiscalibe.priceminister.com:................ done
rfm.priceminister.com:................ done
preview.priceminister.com:................ done
pcdoccasions.vnunet.fr:................ done
ofup.priceminister.com:................ done
occasion.rueducommerce.fr:................ done
occasion.presence-pc.com:................ done
occasion.liberation.fr:................ done
occasion.camif.fr:................ done
mobilokaz.priceminister.com:................ done
mobilesachat.priceminister.com:................ done
m6.priceminister.com:................ done
m6net.priceminister.com:................ done
m6music.priceminister.com:................ done
m6game.priceminister.com:................ done
koobuycity.priceminister.com:................ done
jeuxvideo.priceminister.com:................ done
freesurf.priceminister.com:................ done
francemobiles.priceminister.com:................ done
europe2.priceminister.com:................ done
epik.priceminister.com:................ done
eglue.priceminister.com:................ done
croix-rouge.priceminister.com:................ done
cinenow.priceminister.com:................ done
bo.priceminister.com:................ done
bo.jmh.lan:................ done
bi.priceminister.com:................ done
bambinoccasion.priceminister.com:................ done






[DEC-494] integration des données jeu buffalo dans la base Création: 20/sept./06 18:41  Mise à jour: 14/sept./07 15:14  Résolue: 12/févr./07 17:14

Etat: Fermé
Projet: Reporting
Composants: Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Charlotte Fachan Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: GZip Archive buffalo_no_buyers.txt.gz     File contact.csv     Zip Archive contact.zip     Zip Archive contact080107.zip     Zip Archive contact100207.zip     Zip Archive contact11122006.zip     Zip Archive contact230107.zip     File contact_15112006.csv     File contact_29112006.csv     Zip Archive contact_311006.zip     File contact_update_15112006.csv     File contact_update_29112006.csv     Text File country.txt     Microsoft Excel planning prévisionnel extraction.xls    
Liens des demandes:
Similaire
similaire à DEC-460 A L'ATTENTION D'AGATHE REMY - JEU BUF... Fermé
Pays:
FRA - France

 Description   
Salut,

ci joint un petit apreçu du projet :

On est partenaire d'un concours organisé par Buffalo Grill.

Date du jeu-concours : du 9 Octobre 2006 au 9 Février 2007

L'objectif est de compléter notre base de données de contact qualifiés. Les internautes qui s'inscrivent sur le site du jeu, www.gratte-moi.com (non ce n'est pas une blague! ;-) peuvent gagner plusieurs lots soit en jouant au jeu du type "instant-gagnant" qui fonctionne sur un système de ticket à gratter soit par tirage au sort (1 par mois)

Lors de l'inscription au jeu, les internautes peuvent accepter de recevoir des offres de PM.
Aphélie (l'agence qui s'occupe du jeu) nous envoi le fichier des nouveaux contacts (visiblement une mise à disposition d'une liste sur internet) qu'il faudrait intégrer dans la base PM => c'est sûrement là que tu interviens !

Deuxiéme point : lors des instants gagnants du jeu, nous proposons également aux internautes participant au jeu de recevoir un bon d'achat de 6¿ pour une première commande. Il faudrait également récupérer ces adresses pour pouvoir leur adresser leur bon de réduction.

On s'en reparle demain

Merci

Charlotte







 Commentaires   
Commentaire de Charlotte Fachan [ 26/sept./06 12:12 ]
Salut Edouard,

on pourrait se voir en début d'aprés midi pour en parler?

Merci

Charlotte
Commentaire de Charlotte Fachan [ 26/sept./06 17:44 ]
Edouard,

donc concernant notre partenariat avec Buffalo grill sur le jeu gratte-moi, quelques nouvelles informations

Aphélie met à notre disposition une URL pour accéder à la liste des nouveaux inscrits. Je ne dispose pas encore de cet accès.
Le fichier sera au format XML a priori.

On s'en parle demain.

Merci

Charlotte
Commentaire de Edouard Laurent [ 27/sept./06 18:49 ]
Notre système accepte des fichiers au format texte (CSV): pour pouvoir intégrer facilement les contacts du jeu gratte-moi il nous faut trouver un moyen de mettre les données recuperees par le jeu au format suivant.

- 2 fichiers .csv :

  - Un fichier contact (CSV) : "email;;;is_cultural_subscriber;;tracking_id;;;is_partner_subscriber;is_hightech_subscriber;is_house_subscriber"
Sachant que les champs "is_quelquechose" doivent etre positionnés à 0 si le contact ne souscrit pas a la newsletter et 1 si il souscrit
etant donnée que c'est une inscription global aux newsletters il faut mettre soit tous les champs "is_quelquechose" a 1 ou 0.

  - Un fichier contact_update (CSV) : "email;nom;prenom;adresse1;adresse2;cp;ville;id_pays;is_partner_subscriber;is_cultural_subscriber;is_hightech_subscriber;is_house_subscriber"
Les champs "is_quelquechose" fonctionne de la meme facon que pour le fichier contact.
Le champ code pays doit respecter la norme priceminister voir fichier joint
Commentaire de Edouard Laurent [ 18/oct./06 15:22 ]
L'import des contacts dans la base est terminé :

voici le comptage des nouveaux inscrits grace au jeu :

SQL> select count(*) from user_account where USR_FIRST_TRACKING_ID = 1568140;

  COUNT(*)
----------
      5020

en fichier attaché, la liste pour Agathe


Commentaire de Edouard Laurent [ 18/oct./06 15:25 ]
le bon fichier et le fichier contact.zip
il suffit de prendre la premiere colone, email adresse
Commentaire de François Le Lay [ 19/oct./06 17:15 ]
Ci-joint la liste des contacts qui ne sont pas acheteurs.
Commentaire de Edouard Laurent [ 31/oct./06 14:47 ]
J'ai fait l'integration des contacts, BI a vous de jouer, le fichier "contact_311006.csv" en fichier attaché.
Commentaire de Edouard Laurent [ 31/oct./06 14:47 ]
C'est un zip finalement :)
Commentaire de François Le Lay [ 02/nov./06 19:08 ]
Les nouvelles personnes à contacter sont dans le fichier dispo à l'URL:
http://intra.priceminister.com/stats/export/marketing/buffalo_final_20061102.txt.gz

Il y en a 3400 environ, le différentiel a été fait avec les adresses de l'envoi précédent pour ne pas leur parler 2 fois de suite.
Commentaire de Jérémie Bennejean [ 15/nov./06 16:14 ]
15/11/2006
Les fichiers sont en PJ :
contact_update_15112006.csv
contact_15112006.csv
Commentaire de Edouard Laurent [ 15/nov./06 16:26 ]
Cela fait : 8338 nouveaux comptes ce coup la et 2665 le coup d'avant
Commentaire de François Le Lay [ 17/nov./06 11:37 ]
Les nouvelles personnes à contacter sont dans le fichier dispo à l'URL:
http://intra.priceminister.com/stats/export/marketing/buffalo_final_20061117.txt.gz
différentiel = 12164 emails sur les 13908.

Commentaire de Charlotte Fachan [ 17/nov./06 12:32 ]
merci !

charlotte
Commentaire de Jérémie Bennejean [ 29/nov./06 16:41 ]
29/11/2006
Les fichiers sont en PJ :
contact_update_29112006.csv
contact_29112006.csv
Commentaire de Jérémie Bennejean [ 29/nov./06 16:53 ]
Il y a 13553 nouveaux comptes.
Commentaire de François Le Lay [ 01/déc./06 11:08 ]
Les nouvelles personnes à contacter sont dans le fichier dispo à l'URL:
http://intra.priceminister.com/stats/export/marketing/buffalo_final_20061129.txt.gz
différentiel = 18698 emails sur les 20875 fournis.
Commentaire de Edouard Laurent [ 11/déc./06 12:00 ]
Suite a mon enquete, on a 3 categories :
utilisé : on doit les garder
a supprimer : on est sur de pouvoir le supprimer
out : personne ne se manifeste sur ce flux
?? : attente de la reponse du partenaire

    write_shopping; Utilisé
    write_preistrend; A supprimer
    write_leguide; Utilisé
    write_ebuyclub; OUT
    write_cnet; a supprimer
    write_pangora; Utilisé
    write_adoc; Utilisé - à confirmer
    write_clubic; Utilisé
    write_pricerunner; Utilisé
    write_jeuxvideo; OUT
    write_firstcoffee; Utilisé
    write_icomparateur; OUT
    write_caloga; Utilisé
    write_dvdpascher; Utilisé
    write_zdnet; OUT
    write_ciao; OUT
    write_kelkoo; Utilisé
    write_all_music_box; Utilisé
    write_cashstore; ??
    write_presence_pc; Utilisé
    write_mobilesachat; ??
    write_shopzilla; a supprimer
    write_soliland; Utilisé
    write_m6; ??

Pour l'affiliation :

effiliation Utilisé
cibleclick Utilisé
xinek Utilisé
tradedoubler Utilisé
Commentaire de Edouard Laurent [ 11/déc./06 13:53 ]
desole ca n'a rien a voir, ne pas prendre en compte le dernier commentaire
Commentaire de Edouard Laurent [ 11/déc./06 15:28 ]
Cela fait : 3586 nouveaux comptes, je mets en piece jointe le fichier des nouveaux inscrits pour le DEC
Commentaire de Edouard Laurent [ 11/déc./06 15:29 ]
contact11122006.zip
Commentaire de François Le Lay [ 11/déc./06 17:27 ]
Les nouvelles personnes à contacter sont dans le fichier dispo à l'URL:
http://intra.priceminister.com/stats/export/marketing/buffalo_final_20061211.txt.gz
différentiel = 4718 emails sur les 5232 fournis.
Commentaire de François Le Lay [ 15/déc./06 12:01 ]
J'ai refait tourner buffalo. Le fichier est le même:
http://intra.priceminister.com/stats/export/marketing/buffalo_final_20061211.txt.gz
Commentaire de Charlotte Fachan [ 15/déc./06 12:16 ]
merci François

Charlotte
Commentaire de Edouard Laurent [ 08/janv./07 09:49 ]
Charlotte, est ce que tu pourrais ajouter en piece jointe le nouveau planning

Merci Edouard
Commentaire de Charlotte Fachan [ 08/janv./07 10:10 ]
voilà...

Charlotte
Commentaire de Edouard Laurent [ 08/janv./07 14:01 ]
Je viens de finir l'integration des contacts Buffalo : je decompte 13 436 nouveaux comptes

en piece jointe le fichiers des nouveaux comptes ( sans le dedoublonage) integrer le 8 janv

Commentaire de Edouard Laurent [ 08/janv./07 14:02 ]
c'est le fichier contact080107.zip
Commentaire de Edouard Laurent [ 23/janv./07 13:56 ]
Cela fait 5 292 nouveaux comptes sur cette periode
Commentaire de Edouard Laurent [ 23/janv./07 13:57 ]
contact230107.zip fichier a transmettre a mille merci

Commentaire de Edouard Laurent [ 12/févr./07 17:13 ]
Cela fait 14 238 nouveaux comptes sur la derniere periode.

Le fichier : contact100207.zip

La doc de suivi : http://wikiexploit.lan:82/doku.php?id=edouard.laurent:projets:marketing:jeu_buffalo


Je ferme le Jira, l'integration est terminé






[DEC-430] J'ai besoin de rapport hebdomadaire sur les meilleurs vendeurs de neuf d'une part, et d'occasion de l'autre : Création: 31/août/06 16:02  Mise à jour: 14/sept./07 14:55  Résolue: 02/nov./06 12:11

Etat: Fermé
Projet: Reporting
Composants: Trading
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Anne Korchia Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
J'ai besoin de rapport sur les meilleurs vendeurs de neuf d'une part, et d'occasion de l'autre :

Avec comme principales caractéristiques :
- Le nombre de vente
- Leurs stocks
- La quantités moyennes par produits
- Le prix moyen de vente
- Le CA par mois moyen

Ceci pour les catégorie suivantes :
Livres anciens
livres
Loisirs créatifs

merci
 


 Commentaires   
Commentaire de Agathe Remy [ 02/nov./06 12:11 ]
D'après Pascal, le reporting demandé a été mis en place via 4D en septembre.
D'autre part, afin d'éviter de faire le même travail dans 4D et BI, toutes les demandes de reporting doivent être validées au préalable par Pascal.

Merci:-)

Cordialement,
Agathe




Migration du mécanisme d'import des fichiers de Phaeton vers Bacchus (EXP-2759)

[EXP-2761] Modification de l'entrée DNS pour ftp.priceminister.com Création: 29/sept./06 13:42  Mise à jour: 25/juin/07 18:59  Résolue: 04/déc./06 11:15

Etat: Résolu
Projet: Exploitation
Composants: Evolution
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Patrice Boulanger Attribution: Patrice Boulanger
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Demander à JET de modifier l'enregistrement DNS pour ftp.priceminister.com

 Commentaires   
Commentaire de Patrice Boulanger [ 29/sept./06 13:47 ]
Le TTL de l'enregistrement ftp.priceminister.com est 1 heure. Pendant ce temps (prévoir la journée pour plus de prudence), les fichiers pourront être déposés sur les deux serveurs FTP pendant ce temps. Il faut s'assurer que le script ftpCompute sur Hercule récupére bien les fichiers sur les deux serveurs.

Vérifier aussi avec le B.I. l'usage qu'ils font du FTP sur Phaeton.
Commentaire de Patrice Boulanger [ 04/déc./06 11:15 ]
Done




[BIN-300] [Finance] : Instabilité des montants en janvier sur Purchases summary by month Création: 07/mars/07 14:49  Mise à jour: 14/sept./07 18:02  Résolue: 27/avr./07 16:29

Etat: Fermé
Projet: Business Intelligence
Composants: Executive
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Philippe Favrot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Agathe,

deux soucis avec le rapport "purchases summary by month" :

1 - écart au niveau des commissions de février avec les chiffres donnés par Titan :
commissions produits :
         Titan : 701 221 euros
         Bo : 700 990 euros
commissions port :
         Titan : 244 013 euros
         Bo : 243 890 euros

2 - les chiffres au titre de "captured payment amount", "captured gross merchandized sold" et "concelling amount" pour le mois de janvier ont bougé par rapport à ceux à de début février (alors que le chiffre de "pending amount" était déjà nul).

Merci
Philippe




 Commentaires   
Commentaire de Agathe Remy [ 09/mars/07 15:49 ]
Les chiffres de BI sont à présent identiques à ceux de Titan.

En effet, une erreur s'était glissée suite à la mise en production de la nouvelle gestion de la TVA.
Elle a été corrigée.

Pour étudier ton deuxième point, il me faudrait avoir un peu plus d'informations : au moins les chiffres à début février et leur date de rafraîchissement.

Cordialement,
Agathe
Commentaire de Agathe Remy [ 27/avr./07 16:29 ]
Philippe,

Je viens de regarder ton écart sur le mois de janvier entre le refraîchissement début férvrier et celui début mars.

En fait, il s'agit d'environ 114¿ qui correspondent à 6 paniers (dont les id sont :41781271,41841327,41845283,42026890,42031986,42075465) autorisés en janvier, puis capturés manuellement le 28/02/2007.
En effet, ces paniers étaient passés en capture denied (SIPS capture failed: Opération impossible (erreur de statut)) à priori par erreur et ont finalement été capturés par le BO fin février.

Cordialement,
Agathe
Commentaire de Philippe Favrot [ 30/avr./07 09:22 ]
Merci
c'est effectivement ce que j'ai noté en comparant les rapports Titran panier coupon article à deux dates différentes.
J'attends maintenant le retour de vacances de Steven pour voir avec lui ce qui s'est passé sur ces transactions et statuer.
Philippe




[DEC-604] [TFV] : Rapport SLTV mensuel Création: 25/juil./07 18:08  Mise à jour: 04/sept./08 14:58  Résolue: 04/sept./08 14:58

Etat: Fermé
Projet: Reporting
Composants: Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Thomas Beylot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
comme convenu, petit jira pour signaler le bug identifié sur le rapport SLTV du mois dernier (en plus du bug du mois d'avant, le rapport généré n'a en fait pas comptabilisé les datas de juin, comme si le rapport était mort)

merci

thomas


 Commentaires   
Commentaire de Agathe Remy [ 27/juil./07 17:50 ]
Thomas,

Je suis désolée, mais je ne comprends pas bien la nature du problème.
J'ai bien compris qu'il y en avait un, mais si tu pouvais détailler un peu, cela nous aiderait beaucoup:-)

Agathe
Commentaire de Thomas Beylot [ 27/juil./07 18:02 ]
c'est simple, le rapport qui est sorti début juillet a pour objectif de filer toutes les datas de juin, et si tu ouvres le doc en fait il n'y a aucune data sur juin... et les datas sur mai sont toujours pourrites.


thomas
Commentaire de Agathe Remy [ 04/sept./08 14:58 ]
Suite au transfert des rapports SLTV dans BI, je ferme ce JIRA qui n'a plus lieu d'être...

Agathe




[BIN-356] [Partner/tracking] : Rapport Pangora Création: 10/août/07 11:10  Mise à jour: 24/sept./07 15:21  Résolue: 14/sept./07 18:51

Etat: Fermé
Projet: Business Intelligence
Composants: Partners
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Charles Decaux Attribution: Samir Beghdadi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Je voudrais mettre en place deux rapports pour Pangora avec qui on va travailler sur un deal rémunéré 10% du VA généré :

- envoyer un rapport journalier contenant le volume d'affaires capturé par Pangora sur la journée précédente avec le détail par tracking de son groupe de tracking
- envoyer un appel à facture (le 5 du mois) avec le volume d'affaires capturé par le partenaire sur le mois précédent, le montant unitaire (en l'occurrence 10%) et donc son revenu en mettant le détail par tracking de son groupe de tracking.

Destinataire du rapport quotidien :
n.preteceille@pangora.com

Destinataires du rapport mensuel :
n.preteceille@pangora.com
m.sakakini@pangora.com

Format d'envoi : excel pour le rapport quotidien, pdf pour le rapport mensuel

Il faudrait bien veiller à ce que la somme des rapports quotidiens correspondent à peu près au montant de l'appel à facture.

Merci

Charles



 Commentaires   
Commentaire de Agathe Remy [ 14/août/07 17:17 ]
Romain,

Peux-tu voir comment intégrer cette demande rapidement dans les priorités BI?

Merci:-)

Agathe
Commentaire de Romain Czornomaz [ 27/août/07 17:44 ]
Samir,

Je te transfère la demande de Charles.
Il faut rédiger les spécifications et développer les 2 rapports.

Bon courage,

Romain
Commentaire de Charles Decaux [ 28/août/07 16:07 ]
Samir,

Notre partenariat avec Pangora étant assez ancien, nous avons toujours des paniers avec des trackings anciens car les internautes mettent ces liens trackés dans leurs favoris.

Il faudrait donc ne créer le rapport que pour les codes de tracking suivants :

1907040 1907041 1907042 1907043 1907044 1907045 1907046 1907047 1907048 1907049 1907050 1907051 1907052 1907053 1907054 1907055 1907056 1907057

A ta dispo pour en parler et merci
Commentaire de Samir Beghdadi [ 03/sept./07 09:58 ]
Bonjour,

La demande a été bien traitée, actuellement en attente pour validation.

Samir
Commentaire de Agathe Remy [ 11/sept./07 18:57 ]
Charles,

La liste de tracking que tu nous as transmise a-t-elle pour vocation d'être fixe et définitive?
Parce que si l'on veut garder un peu de souplesse pour créer de nouveaux trackings Prangorax qui seraient pris en compte automatiquement dans les rapports, une solution serait de prendre les trackings dont le code est supérieur ou égal à 1907040 (ce sont des compteurs) ou bien dont la date de creation est supérieure ou égale au 10/08/2007.

Qu'en penses-tu?

A ta dispo pour en discuter.

Agathe
Commentaire de Agathe Remy [ 14/sept./07 16:53 ]
Charles???
Commentaire de Charles Decaux [ 14/sept./07 17:00 ]
Salut Agathe,

il faut que le truc soit souple car il se peut qu'on ait envie d'ajouter de nouveaux trackings.
A priori on ne va plus utiliser les anciens trackings, donc avec ta reco (soit code supérieur à 1907040 ou date supérieure à 10/08/2007)

Merci

Commentaire de Samir Beghdadi [ 14/sept./07 18:51 ]
à valider
Commentaire de Agathe Remy [ 19/sept./07 10:42 ]
Les 2 rapports sont validés.

Samir, peux-tu les passer en production?

Merci:-)
Agathe
Commentaire de Agathe Remy [ 19/sept./07 20:08 ]
Charles,

Peux-tu valider ces deux rapports avant que nous programmions leur envoi à Pangora?

Merci:-)

Agathe
Commentaire de Charles Decaux [ 24/sept./07 10:10 ]
c'est bon merci




[APP-17720] Parrainage : parrainage d'un même email par deux parrains différents Création: 05/sept./07 16:58  Mise à jour: 16/avr./10 15:26  Résolue: 08/avr./10 10:01

Etat: Fermé
Projet: Application PriceMinister
Composants: Parrainage
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 67.0.0 (CTN-Q)

Type: Bogue Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Dispatcher (Pôle CTN)
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Site: Prod
Projets PM: Parrainage (Lot 1)
Classif FONC: parrainage

 Description   
Voici le mail de 1000Mercis :
"Nous avons eu la semaine dernière un souci avec l'email automatique relance filleul J+15 : un filleul a été saisi (par deux parrains différents : pas d'effet Parkinson) deux fois à moins d'1h d'intervalle.

extrait de la table sponsorship correspondant :

sponsorship_id creation_date change_date spo_status_code spo_typ_code parent_account_id child_account_id
148611147 2007-08-17 17:00:28.000 2007-08-17 17:07:40.000 20 20 14676164 14744509
148611322 2007-08-17 16:36:01.000 2007-08-17 17:07:16.000 20 20 11673158 14743678
 
extrait de la table user_account pour le filleul en question :
user_account_id login usr_title_code first_name last_name email_address usr_type_code creation_date sponsorship_id
14743678 teamspirit1 10 colette braud kdxteam@hotmail.fr 10 2007-08-17 16:36:00.000 148611322
14744509 NULL NULL arno NULL kdxteam@hotmail.fr 40 2007-08-17 17:00:28.000 148611147

Il me semblait que ceci n'était pas possible, un individu ne pouvant pas être parrainé plus d'une fois par an ?
La présence de doublons dans la cible provoquant le non envoi de l'email automatique, pourrais-tu me dire si ceci est un cas exceptionnel, ou un assouplissement de la règle qui doit nous conduire à revoir la procédure de ciblage automatique ?
"

Et voici la réponse d'Alexandre :
"Ce cas n'aurait pas du arriver : lors d'un parrainage, si l'adresse mail est déjà dans la base, on tente de reparainner l'utilisateur si possible (inactif depuis plus de 12 mois, ...).
Il semble donc y avoir un petit souci, un JIRA serait le bienvenue pour voir ça et essayer de trouver une solution.
Petit historique :
- 03/09/06-11:16 : A s'inscrit
- 03/08/07-12:00 : A parraine B
- 03/08/07-12:35 : B s'inscrit
- 17/08/07-16:36 : A parraine C
- 17/08/07-16:54 : C s'inscrit
- 17/08/07-17:00 : B parraine C' (au lieu de se faire jeter à tenter de parrainer C)
(Remarque : entre B et C : chacun possède comme pseudo le mot de passe de l'autre ...)
"

Merci:-)

Agathe

 Commentaires   
Commentaire de Alexandre Garnier [ 11/sept./07 15:36 ]
select * from spo_event where sponsorship_id in (148611147,148611322);

SPO_EVENT_ID SPONSORSHIP_ID CREATION_DATE SPE_TYPE_CODE
-------------------------------------------------------------------------------------------------------------------------
     2525929 148611322 17/08/2007 16:36:01 10
     2525994 148611322 17/08/2007 17:07:16 20
     2525980 148611147 17/08/2007 17:00:28 10
     2526029 148611147 17/08/2007 17:07:40 20
Commentaire de Alexandre Garnier [ 20/sept./07 18:56 ]
Cas tordu qui ne doit quasiment jamais arriver, faudrait se pencher dessus pour voir.
Commentaire de Fabrice Feugas [ 19/janv./10 16:34 ]
Toujours d'actualité ? On a pu reproduire ? Si non, won't fix...
Commentaire de Fabrice Feugas [ 17/févr./10 12:16 ]
A noter : on va réduire la période de gel des filleuls de 12 à 3 mois. Les gens seront donc "reparrainables" au bout de 3 mois, y compris ceux qui se sont inscrits d'eux-même mais qui n'ont fait aucune action sur le site.

De même, suite à cette modification il y a toute un lot de parrainage que nous allons faire expirer (ceux qui auront une date de création supérieure à 3 mois) et qui seront reparrainables.

On en reparlera avec BI pour maitriser les impacts de ces modifications.
Commentaire de Fabrice Feugas [ 08/avr./10 10:01 ]
Sous contrôle d'Alexandre, on a traité ce problème dans le cadre du projet parrainage lot 1.




[Finance] : Adaptation fonctionnelle de la gestion de la TVA pour les rapports BI pour les PLF rance et Espagne (BIN-273)

[BIN-332] [Finance] : Liste des transactions non soumises à TVA sur les sites France et Espagne Création: 11/mai/07 19:26  Mise à jour: 23/nov./07 12:26  Résolue: 23/nov./07 12:26

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sub-improvement Priorité: Majeur
Rapporteur: Claudie Dufresne Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Agathe,

Dans le cadre des déclarations mensuelles de TVA notamment, nous devons pouvoir justifier les montants déclarés en exonération de TVA tant sur les transactions du site Français que sur celles du site Espagnol.

Il faudrait donc mettre en place une requête permettant d'obtenir l'ensemble des transactions exonérées de TVA pour le mois écoulé avec les informations suivantes :
- les mêmes que sur l'extraction du mois de mars (item id - seller account - payment contry - compensation country - expedition country - seller type - product type - n° intracom - VAT Rate)
- avec en plus une colonne mentionnant le montant (HT) de la transaction

N'hésite pas si tu as besoin d'information complémentaire ou explication
Merci
claudie


 Commentaires   
Commentaire de Agathe Remy [ 14/mai/07 10:54 ]
Romain,

Peux-tu commencer les spécifications fonctionnelles?

Merci:-)

Agathe
Commentaire de Romain Czornomaz [ 27/juil./07 16:00 ]
Claudie,

Le rapport "Captured VAT exempted items by authorization month" a été déployé en france et en l'espagne sur la plateforme BI.

Peux tu valider les rapports et cloturer la demande?

Merci d'avance,

Romain
Commentaire de Claudie Dufresne [ 30/juil./07 14:48 ]
Romain,

j'ai fait le test sur la période de juin, c'est ok.
Juste une petite remarque,
est-il possible de rajouter un total sur la colonne "Commission net"
merci à toi
claudie
Commentaire de Romain Czornomaz [ 30/juil./07 15:08 ]
Claudie,

Les modifications sont faites :)
Le total sur la colonne "comission net" est present sur les 2 rapports France et Espagne.

Bonne journée,

Romain
Commentaire de Claudie Dufresne [ 30/juil./07 16:28 ]
Tout est ok pour moi,
merci à toi Romain !
Commentaire de Claudie Dufresne [ 26/oct./07 14:10 ]
Agathe, Romain,

Pouvez-vous relancer la requete pour nous permettre de connaitre les vendeurs pro "CEE" qui n'auraient toujours pas renseigné de numéro intracommunautaire.

merci à vous

claudie
Commentaire de Romain Czornomaz [ 23/nov./07 12:26 ]
Claudie,

Je ferme la demande, je 'tai envoyé le 26Oct la liste des vendeurs exemptés de TVA pour la France et l'Espagne.

tu pourras la réouvrir pour avoir la liste à jour.

Bonne journée,

Romain




[APP-16778] demande code velocity pour surveiller nombre d'annonces dans une catégorie. Création: 22/juin/07 15:47  Mise à jour: 31/juil./07 19:28  Résolue: 20/juil./07 09:56

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 14.2.1
Version(s) corrigée(s): 16.0.0

Type: Amélioration Priorité: Majeur
Rapporteur: Cedric Favero Attribution: Geneviève Beaujard
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Classif1: BO
Classif2: fraude

 Description   
Toujours en raison des problèmatiques de contrefaçon , il nous faudrait pouvoir avoir la possiblité de detecter les utilisateurs qui ont plus d'un certain nombre d'annonces dans une catégorie donnée.

Actuellement on peut detecter par la profondeur de stock:
ex: $advert.availableCount.intValue() > 5 (pour une profondeur de stock superieure à 5)

Mais celà ne permet de detecter que ceux qui ont une quantité supérieure à 5 sur une meme annonce.

Il nous faudrait pouvoir detecter ceux qui ont plus de X annonces dans une certaine catégorie:
ex: plus de 10 annonces dans la rubrique parfums ou maroquinerie

Quel serait le code correspondant pour cette fonctionnalité?

Merci.

 Commentaires   
Commentaire de Cedric Favero [ 22/juin/07 15:49 ]
Dans le meme esprit , est-il possible de detecter un comportement comme suit? :

tel vendeur a vendu plus de x produits de telle catégorie dans tel délai.

ex: utilisateur a vendu plus de 20 parfums dans les 6 derniers mois.
Commentaire de Edouard Gomez-Vaez [ 17/juil./07 09:10 ]
Geneviève, peut-être avons nous déjà l'info à dispo, alors nous pourrons la mettre dans le contexte si elle n'y est pas. Sinon, on regarde ensemble.
Commentaire de Geneviève Beaujard [ 20/juil./07 09:56 ]
Desolé cher cedric, mais ce que tu demandes releve plus du BI.
Commentaire de Cedric Favero [ 20/juil./07 09:58 ]
Merci on s'y interessera donc un peu plus tard par l'intermédiaire de Business Objects.




[APP-16863] relance coupon alors qu'utilisateur a déjà acheté Création: 29/juin/07 16:29  Mise à jour: 13/janv./09 11:41  Résolue: 20/sept./07 16:24

Etat: Fermé
Projet: Application PriceMinister
Composants: Mails
Affecte la/les version(s): 14.2.1
Version(s) corrigée(s): 38.0.0 (TX-D Bis)

Type: Bogue Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: *** RESERVE ***
Classif1: MON COMPTE
Classif2: coupon

 Description   
Pseudo: jpds110

On lui envoie le 29/06 un message:


"Rappel : votre bon cadeau de 6 euros est toujours valable !
De: "PriceMinister" <news@newsletter-priceminister.com> Ajouter au carnet d'adresses Yahoo! DomainKeys a confirmé que ce message a été envoyé par newsletter-priceminister.com. En savoir plus À:..."

Pb : il a déjà acheté le 14/06!

Comment se fait-il qu'on envoie ce type de relance?

 Commentaires   
Commentaire de Renaud Dierickx [ 05/sept./07 09:51 ]
Je ne trouve pas ce mail dans l'api...
C'est un mail envoyé par le BI / Marketing ?
Pouvez-vous me le confirmer ?
Merci.
Commentaire de Agathe Remy [ 05/sept./07 10:10 ]
En effet, ce mail est une campagnes réflexe Marketing envoyée par 1000Mercis.

Il faut remonter cela à Alexandra : a priori il y a un pb dans les ciblages faits par 1000Mercis. D'un autre côté, entre le 15 et le 30 juin, il y a eu la migration technique des bases de données PM qui nous a forcé à suspendre la mise à jour des données chez nos partenaires. Peut-être que ce ciblage erroné en est un impact??? Cédric, as-tu d'autres exemples de ce type à une autre période?
 
Pour info, ce mail fait partie d'une série de 4 mails envoyés aux nouveaux inscrits non acheteurs. Le 1er mail est envoyé si un inscrit n'a pas acheté sur PM 45 jours après son inscription, les autres mails étant des relances à 15j, 30j, puis 45j suivant.
Et je viens de retrouver un mail du 30/04/2007 d'Odile prévenant Steven et Claire.

Peut-on fermer ce JIRA?

Merci:-)

Cordialement,
Agathe
Commentaire de Cedric Favero [ 19/sept./07 16:36 ]
je n'ai pas d'autre cas similaires à signaler.
On peut fermer le JIRA..




[BIN-420] [LRO] : Nombre de vendeurs/nouvelles ventes emailing La Redoute Occasion Création: 28/févr./08 10:11  Mise à jour: 14/mai/09 17:00  Résolue: 10/juin/08 17:19

Etat: Fermé
Projet: Business Intelligence
Composants: Partners
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Aurélie Maccario Attribution: Florian Ambrosi
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel la redoute tracking emailing1.xls     Microsoft Excel la redoute.xls    
Liens des demandes:
Similaire
similaire à BIN-560 [Marketing] : Vérification du rapport... Fermé
Pays:
FRA - France

 Description   
Bonjour,

Nous aimerions construire un rapport qui nous permette de mesurer le nombre de nouvelles mises en vente et de nouveaux vendeurs suite à l'envoi d'un mailing pour La Redoute par Redoute sur tous les contacts La Redoute Occasion. Ce mailing est tracké Opération LaRedoute Occasion dans "tracking 1" (et non le tracking du brand).

Est-ce possible ?

Merci

Aurélie

 Commentaires   
Commentaire de Agathe Remy [ 28/févr./08 10:59 ]
Bonjour Aurélie,

Pourrais-tu préciser :
- le contexte
- l'objectif
- l'impact business attendu
- l'urgence de la demande
?

Merci.

Agathe
Commentaire de Aurélie Maccario [ 28/févr./08 11:39 ]
Bonjour Agathe,

Il s'agit en fait d'une newsletter qui a été envoyée en février aux contacts de La Redoute Occasions. Elle n'était pas orientée "promotion" mais plutôt "vente" (pousser les abonnés à vendre des articles).

Afin de voir si le message a bien fonctionné, nous souhaitons connaître le nombre de nouveaux vendeurs suite à cette news pour faire un bilan à La Redoute.

Cela nous servira donc pour les prochaines news que nous allons envoyées.

Nous souhaiterions faire un retour à La Redoute dans la journée.

Je reste à ta disposition si tu as besoin d'autres précisions.

Merci.

Aurélie
Commentaire de Agathe Remy [ 28/févr./08 12:02 ]
Dans la journée me parait un délai plus qu'illusoire...
Nous pouvons te proposer de fournir ces données la semaine prochaine.
Est-ce que cela te convient ou bien annulons-nous la demande?

Merci.

Agathe
Commentaire de Aurélie Maccario [ 28/févr./08 12:09 ]
Agathe,

Je suis désolée, je suis nouvelle je ne savais pas qu'il y avait un planning assez chargé.

La semaine prochaine serait parfait.

Merci beaucoup pour tes réponses rapides.

Aurélie
Commentaire de Florian Ambrosi [ 04/mars/08 17:30 ]
Aurélie,

Je te joint un fichier Excel répondant à ta demande.

Si tu as des questions, je suis à ta dispo.

Florian.
Commentaire de Florian Ambrosi [ 05/mars/08 11:23 ]
Aurélie,

Comme vu ce matin, je te joint le fichier avec seulement le tracking emailing1 de la redoute occasion.

Désolé pour la confusion.

Florian.
Commentaire de Florian Ambrosi [ 05/mars/08 18:05 ]
Agathe,

Peux-tu valider le rapport "Public Folder/Développement/Advert/", ainsi que les specs "V:\Reporting\BusinessIntelligence\En Développement\2008-02 followup sales newsletter"?

Merci.

Florian
Commentaire de Thomas Beylot [ 06/mars/08 11:22 ]
Bonjour

je me permet d'intervenir dans ce jira suite à discussion avec Agathe lundi.

En effet je pense qu'il faudrait peut être mieux préciser la demande pour éventuellement en faire un rapport que l'équipe marketing dans son ensemble pourrait utiliser non ?

Souhaitez vous un brief plus précis ?


merci

Thomas
Commentaire de Ghislain Gridel [ 17/mars/08 14:19 ]
oui. Merci Thomas.
Commentaire de Thomas Beylot [ 14/mai/08 18:02 ]
Salut

de retour après une longue absence sur le sujet, je voulais savoir si au delà des deux rapports attachés en pj (qui ont l'air bien) on avait la possibilité de tester le rapport sur Bi ?

> peut-on choisir le groupe de tracking et/ou tracking name
> peut-on avoir les catégories de mise en vente associées ?

thomas.
Commentaire de Florian Ambrosi [ 26/mai/08 14:07 ]
Agathe,

C'est passé en production en France et en Espagne.

Florian
Commentaire de Agathe Remy [ 10/juin/08 15:51 ]
Agathe,

Pour le rapport de ce matin (nombre de vente par rapport à un code de tracking) quand je génère le rapport pour la news LRO il est nul alors que nous avons envoyé une news le 18 mai.

Le tracking est LRO_emailing_mai.

Est-ce que Florian aurait le temps d'y jeter un coup d'¿il ? Dois-je fais un JIRA ?

Merci par avance pour ton retour et bonne journée.

--
Aurélie Maccario
www.PriceMinister.com
Tél : 01 42 78 83 96
Commentaire de Florian Ambrosi [ 10/juin/08 17:19 ]
Le problème est normalement résolu. Le rapport est déployé en France et en Espagne.

Florian
Commentaire de Aurélie Maccario [ 10/juin/08 17:27 ]
Ok super ça marche maintenant.

Merci beaucoup et bonne fin de journée !

Aurélie




[PMV : Migration des Anciens Vendeurs] (APP-21971)

[APP-22049] Migration du lot 6 : Particuliers par virement avec un PMV non activé Création: 05/sept./08 18:25  Mise à jour: 09/oct./08 11:33  Résolue: 02/oct./08 15:28

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): 27.0.1
Version(s) corrigée(s): 31.0.0 (TX-C)

Type: Sous-tâche Priorité: Majeur
Rapporteur: Arnaud Forgues Attribution: Arnaud Forgues
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Projets PM archivés: Paiement - Migration anciens vendeurs

 Description   
Dans ce lot, on migre les utilisateurs particuliers actuellement en privilège SILVER (virement) dont le PMV n'est pas encore activé (sauf les vendeurs -2, qui par construction auront déjà été migrés dans le lot 1) en privilège Platine mode libre sans configuration des reversement du PMV.

Ces utilisateurs seront soumis à une communication par mail des changements liés à cette migration : en effet, ils devront activer leur PMV puis configurer une demande de reversement ponctuelle ou régulière par virement afin de recevoir à nouveau les paiements de leurs ventes.

 Commentaires   
Commentaire de Arnaud Forgues [ 02/oct./08 15:28 ]
La migration est effective.

Le ciblage est en cours au BI et le mailing d'accompagnement sera envoyé samedi prochain.




[BIN-482] [Finance] : Nouveau rapport "seller bonus" Création: 05/sept./08 16:07  Mise à jour: 23/oct./09 10:15  Résolue: 19/oct./09 16:57

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Claudie Dufresne Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Agathe, Dalila,

Toujours dans le cadre de la justification de la dette vendeur, il reste un rapport à créer.
Il s'agit de pouvoir justifier le solde des SELLER BONUS à payer à la fin d'une période.

Comme pour le rapport "seller credit", il faudrait créer le rapport sur la base de la date "claim closing date" et reprenant les info suivantes : item id, seller login, authorization date, claim closing date, claim status, ...

Du fait du volume important sur la France, il serait je pense nécessaire, comme pour le seller credit, d'ouvrir deux rapports :
seller bonus summary
seller bonus détaillé

A votre disposition si vous avez besoin d'info complémentaires ou précisions.

claudie


 Commentaires   
Commentaire de Dalila Belkebir [ 19/oct./09 16:57 ]
 Bonjour,

Deux nouveaux rapports sont maintenant disponibles dans le BI :
¿ Seller bonus summary by claim closing date
¿ Seller bonus by claim closing date and authorization month

Ces rapport a pour objectif de permettre la justification du solde des SELLER BONUS à payer à la fin d'une période.

Il sont disponibles :
- Dans le repertoire Financial/Accouting visible par l'équipe DAF uniquement
- Sur chacune des plateformes : France, SPAIN & UK !

Lors de la réalisation de spécifications nous avons marginalisé des transactions avec des réclamations avec bonus et en statut « rejected ».
Ces transactions permettent de justifier l'écart de 26.7¿ sur la France :

ITEM ID SELLER BONUS STATUS AUTHORIZATION_DATE
1416609 5 rejected 06/10/2002
1422183 1,7 rejected 07/10/2002
1720358 20 rejected 15/11/2002
Total 26,7

Merci de nous faire part de vos retours pour validation du JIRA.

Cordialement,
Dalila.
 
57, boulevard de la Villette
75010 Paris - France
Tel :01.42.78.97.49
 






Commentaire de Dalila Belkebir [ 23/oct./09 10:15 ]
Validé par Claudie le 23/10.

De : Claudie Dufresne [mailto:claudie.dufresne@priceminister.com]
Envoyé : vendredi 23 octobre 2009 10:08
À : 'Julien Girardet'
Cc : philippe.favrot@priceminister.com; 'samira remila'; 'Dalila Belkebir'
Objet : RE: [JIRA] Résolue: (BIN-482) [Finance] : Nouveau rapport "seller bonus"
Importance : Haute

Bonjour Julien
Tout est ok pour moi ! c'est top !
Un rapport de plus qui nous sera bien utile !
Merci bcq à toi
claudie



Dalila.




[APP-22032] [CO MARKET] Opération SFR EEEPC Création: 05/sept./08 11:53  Mise à jour: 16/sept./08 14:43  Résolue: 16/sept./08 12:16

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 28.0.2.1

Type: Tâche Priorité: Majeur
Rapporteur: Benjamin Guerville Attribution: Olga Costa
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: File Portables1000.fla     File Portables1000.swf     File priceminister.swf    
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-22214 PRE DEPLOY]ActiveActiver les liens ve... Sub-improvement Fermé Yassine Mouhammadou  
Pays:
FRA - France
Projets PM: *** A PLANIFIER ***

 Description   
Bonjour,
Nous avons eu le GO de la régie. L'idée est donc de mettre en ligne l'opération au plus vite et pour 3 semaines.

Il y a 3 points :
- Mise en place d'un lien "xxx" dans le menu déroulant bleu Informatique (tout en bas)
- Mise en place d'un lien "xxx" dans la npf informatique (en bas à droite".
- Création d'une page IG accessible depuis ces liens et hébergeant une créa SFR.

Il manque encore :
- Le wording des liens "xxx"
- L'url de la créa

Je reviens vers vous au plus vite.

Merci de votre coopération !

Benjamin

 Commentaires   
Commentaire de Benjamin Guerville [ 05/sept./08 14:08 ]
Serait-il possible que vous me communiquiez l'url de la page IG même si celle-ci n'est pas encore crée ?

ça pourrait être par exemple :
http://www.priceminister.com/info/no/op/SFR

merci
BG
Commentaire de Olga Costa [ 05/sept./08 14:08 ]
Bonjour
Thomas il faut que j'ai les éléments aujourd'hui.
Merci
Commentaire de Benjamin Guerville [ 05/sept./08 14:41 ]
Merci de penser à mettre un tag XITI sur la page IG.
Commentaire de Benjamin Guerville [ 05/sept./08 15:59 ]
Il serait aussi intéressant de pouvoir suivre le nombre de clic sur chacun des liens, par le biais de 2 tracking différents par exemple.
Merci
Commentaire de Olga Costa [ 05/sept./08 16:34 ]
http://www.priceminister.com/info/no/op/sfr c'est mieux avec les minuscule
Commentaire de Olga Costa [ 08/sept./08 10:25 ]
Bonjour Benjamin,
Est ce que tu as les éléments?

Merci Olga
Commentaire de Olga Costa [ 09/sept./08 11:36 ]
Benjamin,
je passe ce jira en v28.0.0.1

Merci
Commentaire de Benjamin Guerville [ 09/sept./08 12:34 ]
Voici les éléments en Flash.
J'aurais le wording des liens texte d'ici peu.

Merci
Commentaire de Benjamin Guerville [ 09/sept./08 12:56 ]
Autres points :
- la flash fait 1000px de large : ok pour moi et validé avec Christophe et Swan (exceptionnelement compte tenu du contexte)

- la page ne doit pas être référencée, brouillage des liens.

Merci
Commentaire de Olga Costa [ 09/sept./08 15:55 ]
http://bo.pm.bollinger:3180/info/no/op/sfr

voila la page
Commentaire de Benjamin Guerville [ 09/sept./08 16:37 ]
Voici le texte à utiliser sur le lien texte pour l'opération SFR - EEEPC (lien menu bleu, lien npf et nom de la page) :

"EeePC : c'est Internet partout"

Le lien à utiliser pour les command clic est :

http://www.smartadserver.com/call/cliccommand/1698506/[timestamp]?

Merci !
Commentaire de Olga Costa [ 10/sept./08 14:03 ]
Contenu publié
 Fabien feras le liens
Commentaire de Benjamin Guerville [ 10/sept./08 15:06 ]
Hello,

Date de fin de l'opé : 04/10/2008

Merci
Commentaire de Fabien Farache [ 10/sept./08 18:22 ]
Mis en place... puis enlevé, suite à la demande de BEG
Commentaire de Benjamin Guerville [ 15/sept./08 10:01 ]
Bonjour,

En pièce jointe, la nouvelle créa du partenaire. Elle remplace l'ancienne.

Une fois la créa mise en place, merci de réactiver les liens.

Merci à tous !

BG
Commentaire de Benjamin Guerville [ 15/sept./08 17:41 ]
Je reviens vers vous au sujet du clic command, en fait il s'agit d'utiliser l'url :

http://www.smartadserver.com/call/cliccommand/1698506/[timestamp]?

à la place de :

http://www.priceminister.com/info/no/op/sfr

afin que la régie puisse compter les clics.

Est-ce ok pour vous ?

Si mise en ligne mercredi 17, nouvelle date de fin d'opé : 09/10/2008

Merci




[BIN-502] [Kpi mev] : Création d'un rapport de suivi des créations de fiches produits en Front Office Création: 22/oct./08 10:00  Mise à jour: 01/déc./08 09:52  Résolue: 01/déc./08 09:52

Etat: Fermé
Projet: Business Intelligence
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Agathe Remy Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word DMR - KPI MEV.doc    
Pays:
FRA - France

 Description   
Contexte :
Le pôle catalogue a modifié le process de mise en vente avec création de fiche produit en déplaçant la connexion/création de compte à la fin du process.
L'objectif de ce projet était d'augmenter le nombre de mev avec création de FP en partant de l'hypothèse que la connexion/création de compte représentait un frein important pour l'internaute et qu'en la déplaçant à la fin du process, celui-ci ayant déjà rempli toutes les étapes de la mev, ce frein serait atténué.
Afin de mesurer l'impact de ce projet, nous voulons mettre en place un rapport quick win permettant de :
- mesurer l'augmentation des créations de fiches produits en Front Office (donc hors imports) dans le temps (le projet a été livré en Production le 18/09/2008).
- comparer ce nombre de fiches produits au nombre total d'annonces créées afin d'évaluer si cette augmentation est uniquement liée à celle de l'activité ou bien également à la livraison du projet.
A voir s'il est pertinent de suivre ces indcateurs par familles/types de produits.

Dans le cas de la mev avec création de FP, le nombre de d'annonces créées est égal au nombre de FP créées.

Agathe


 Commentaires   
Commentaire de Dalila Belkebir [ 30/oct./08 19:16 ]
Benoit, Agathe,

J'ai chargé les spécifications des rapports à mettre en place (un par famille de produits et un autre par type de produits).
Merci de me faire part de vos retours ou validation pour implémentation.

Dalila.
Commentaire de Thomas Beylot [ 31/oct./08 18:51 ]
hello

je me permets d'intervenir dans ce jira pour préciser qu'à mon avis des kpi qui n'utiliseraient que bi ne seraient pas super pertinents... il faudrait utiliser xiti et comparer le tunnel de mev avant/après et observer la fuite (ou pas) des visiteurs.

thomas




[DEC-630]  [PMV - Migration des Anciens Vendeurs] : extraction des cibles pour le mailing Création: 18/sept./08 19:07  Mise à jour: 15/oct./08 09:54  Résolue: 15/oct./08 09:54

Etat: Fermé
Projet: Reporting
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Agathe Remy Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ESP - Espagne, FRA - France

 Description   
Dans le cadre de la migration des anciens vendeurs en privilège Platine, il s'agit de réaliser les extractions de cibles pour les mailings d'accompagnement.
- 3 lots :
        1) Vendeurs Particuliers par Chèque
        2) Vendeurs Particuliers par virement dont le PMV est activé
        3) Vendeurs particuliers par Virement dont le PMV n'est pas activé
- 1 mail par lot avec 2 versions => 2 extractions par lot
1 version Price
1 version Brand

Le 1er mail doit être envoyé le 25/09 et concerne les vendeurs payés par chèque qui seront migrés le 23/09. Les extractions devront donc être fournies à 1M le 24/09.
Le 2ème mail est prévu le 04/10 et concerne les vendeurs payés par virement dont le PMV est activé et dont la migration est prévue le 01/10. Les extractions devront donc être fournies à 1M le 03/10 au plus tard.
Le 3ème mail est prévu le 13/10 et concerne les vendeurs payés par virement dont le PMV n'est pas activé et dont la migration est prévue le 10/10
 => problème puisque le 10 est un vendredi et le 13 un lundi...

Les informations à fournir sont :
pseudo et email pour le fichier PM
pseudo, email, brand name et brand url pour le fichier Cobranding


 Commentaires   
Commentaire de Agathe Remy [ 18/sept./08 19:08 ]
Concernant les critères de ciblage de ce lot n°4, je confirme donc au BI les infos suivantes :
=> Baser la cible sur l'événement dans USR_EVENT avec
- use_type_code = 900 (WALLET_CONFIG_UPDATE)
- description LIKE 'Migration en mode platine Lot 4%'
- creation_date > TO_DATE('22/09/2008', 'DD/MM/YYYY')

Pour les lots 5 et 6 qui auront lieu le 1er puis le 10 octobre, ce sera la même chose en remplacant :
- « Lot4 » par « Lot 5 » ou « Lot 6 »
- La date de creation

Pour les infos brand, on aura donc :
- Le nom du brand &#61672; « brand_name » de la table « brand »
- L'url de la HP du brand &#61672;IF brand.host IS NULL THEN brand.alias || 'priceminister.com' ELSE brand.host END IF;

A noter qu'on ne devrait pas avoir de cobrand pour l'envoi en Espagne, sauf peut etre les www et bo à considérer comme www ?

Voilou,

Arnaud Forgues
Commentaire de Agathe Remy [ 15/oct./08 09:54 ]
C'est fini!
Youpi:-)
Agathe




[IMP-3506] problèmes de caractères accentués: livre-revue Création: 08/avr./09 10:12  Mise à jour: 30/oct./09 15:51  Résolue: 27/avr./09 09:50

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Anne Korchia Attribution: Frédéric Nahum
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Zip Archive Fichier livre-revue.zip    
Pays:
FRA - France
Login: livre-revue
Séparateur: N/A
Type de traitement:
N/A

 Description   
problèmes de caractères accentués : ceux ci ne passent pas correctement sur le site (à la place des é, è, ê ou autre j'ai des hiéroglyphes). Je pense que c'est parceque je travaille et gère ma base de données depuis un oridnateur sous Mac OS. Pourriez vous, pour faire simple, paramétrer mes imports de base de données strictement comme ceux du compte bpettit (mail : librairie.pettit@noos.fr), que je gère également depuis le même ordinateur avec le même OS, et qui ne pose aucun problème avec les caractères accentués


 Commentaires   
Commentaire de Frédéric Nahum [ 08/avr./09 18:22 ]
Le format est pourtant déja parmétré pour mac c'est bizarre il doit avoir a la base déja un problème avec son fichier, demande lui de t'envouer son fichier directement par mail pour qu'on puisse l'analyser en direct
Commentaire de michalon [ 08/avr./09 18:41 ]
la version brut (directement issue de mon mac (Mac OS 10.5.6), enregistrée au format txt) et la version retraitée en UFT8 par le biais du logiciel TextEdit (cette fonction permet de corriger les problèmes d'accent sur mon autre compte : bpettit ; mais pas sur ce compte livre-revue, donc)
Commentaire de michalon [ 15/avr./09 14:39 ]
salut
où en est la demande?

merci
Commentaire de michalon [ 21/avr./09 15:32 ]
salut
où en est la demande?

merci
Commentaire de Frédéric Nahum [ 27/avr./09 09:50 ]
c'est fait il faut donc a l'avenir que le pro nous envoi sont fichier en UTF8




[APP-24124] Utilisation incorrecte des adresses sources dans les mails de parrainage Création: 02/févr./09 18:02  Mise à jour: 12/juin/09 15:45  Résolue: 11/juin/09 12:19

Etat: Fermé
Projet: Application PriceMinister
Composants: Mails, Parrainage
Affecte la/les version(s): 39.0.0 (CTN-I)
Version(s) corrigée(s): 48.0.0 (CTN-L)

Type: Amélioration Priorité: Bloquant
Rapporteur: Patrice Boulanger Attribution: Damien Dorizy
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: JPEG File app24124.JPG    
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-25575 Changement expéditeur des mails appli... Sub-bug Fermé Damien Dorizy  
APP-25577 [Mails Parrainage] Traduction du nom ... Sub-bug Fermé Dispatcher (Traduction)  
Pays:
ALL - Tous
Site: Prod
Projets PM: *** RESERVE ***
Classif FONC: tech

 Description   
Beaucoup de mails de parrainage sont rejetés par les relais de messagerie car le paramétrage de ces courriers n'est pas valide.

En effet, on forge (rien à voir avec Arnaud) l'adresse de l'émetteur à partir du compte du parrain. Or, plusieurs mécanismes, et en particulier SPF (Sender Policy Framework) sont exactement fait pour empêcher ce type de manipulation.

Illustration par les logs de graces:

Feb 2 04:18:33 graces00 postfix/smtpd[7241]: 1E14814220: client=hercule02.atlantide.jmsp.net[10.150.28.77]
Feb 2 04:18:33 graces00 postfix/cleanup[7242]: 1E14814220: message-id=<19815760.1233544713120.JavaMail.nobody@nosuchhost.nosuchdomain.com>
Feb 2 04:18:33 graces00 postfix/cleanup[7242]: 1E14814220: warning: header Subject: AUDERAVASSON, voici 7 Euros offerts de la part de reuse from hercule02.atlantide.jmsp.net[10.150.28.77]; from=<couzen4@hotmail.fr> to=<marieano@hotmail.fr> proto=ESMTP helo=<hercule>
Feb 2 04:18:33 graces00 postfix/nqmgr[28793]: 1E14814220: from=<couzen4@hotmail.fr>, size=22664, nrcpt=1 (queue active)
Feb 2 04:18:34 graces00 postfix/smtp[6341]: 1E14814220: to=<marieano@hotmail.fr>, relay=mx2.hotmail.com[65.54.244.40], delay=1, status=sent (250 mail from IP 212.23.167.26 soft failed sender ID check. Please ensure this IP is authorized to send mail on behalf of [hotmail.fr])
Feb 2 04:18:34 graces00 postfix/nqmgr[28793]: 1E14814220: removed

A noter le message du relais:

sent (250 mail from IP 212.23.167.26 soft failed sender ID check. Please ensure this IP is authorized to send mail on behalf of [hotmail.fr])

En clair:

- on ne peut le détecter car le relais répond 250, donc OK en gros
- très peu de chance que le message ne soit délivré au(x) destinataire(s) par la suite.
- risque de perdre de plus en plus de mails de parrainage si d'autres gros domaines paramètrent SPF dans leur DNS

Il faut donc changer la façon de construire ces mails applicatifs.


 Commentaires   
Commentaire de Patrice Boulanger [ 02/févr./09 18:27 ]
Mes préconisations pour la construction de ces emails:

Return-Path: indique à quelle adresse doivent être envoyées les réponses automatiques du serveur (no delivery par exemple)
valeur: mailer@priceminister.com

Reply-To: indique l'adresse à laquelle une réponse éventuelle du destinataire va être envoyé (quand on clique sur Répondre dans outlook par exemple).
valeur: devrait être une adresse en priceminister.com => BO ?

From: ce qui apparaîtra si on regarde le mail avec Outlook ou un webmail. Le format devrait être:
"Prénom Nom" <mailer@priceminister.com> avec "Prénom Nom" qui peut être ce que vous voulez.

Merci.
Patrice.



Commentaire de Justin Ziegler [ 02/févr./09 18:45 ]
ne peut on mettre l'adresse email du parrain dans le "reply-to" ?
Commentaire de Fabrice Feugas [ 03/févr./09 11:12 ]
N'y avait-il pas une valeur juridique dans le fait que le filleul doit recevoir l'email parrainage en provenance de l'adresse email de son parrain (parrain@hotmail.fr par exemple) et non d'une adresse @priceminister.com ?
Commentaire de Justin Ziegler [ 03/févr./09 11:26 ]
Non, c'était une volonté marketing. On pensait que c'était mieux !
(on n'avait pas de juriste à l'époque)
Commentaire de Fabrice Feugas [ 03/févr./09 14:49 ]
Ok donc vraiment pas de contre-indication à cette modification. Patrice, est-ce que tu penses que les SPF nous bloqueront si on met l'email parrain dans le "reply-to" ?
Commentaire de Justin Ziegler [ 03/févr./09 15:02 ]
Un peu de doc :

http://idunno.org/archive/2004/10/18/133.aspx

Commentaire de Benoit Tabaka [ 03/févr./09 16:05 ]
Sur le plan juridique, pas bloquant.

La CNIL demande uniquement que le nom du parrain (expéditeur) soit clairement mentionnée (le mieux dans l'entête du message, comme expéditeur) mais la CNIL ne demande pas pour autant que l'adresse mail du parrain apparaisse.
Commentaire de Cedric Favero [ 03/févr./09 17:15 ]
Sauf qu'avec mailer@priceminister.com , on a plein de problemes de blacklisting (ex hotmail pour lesquels des utilisateur ne recoivent plus aucun mail de notre part). => Plutot utiliser nepasrepondre@priceminister.com

Et que donner l'adresse email du parrain , c'est pas génial niveau confidentialité, surtout dans le cas des parrainages Widget ou le filleul ne connait pas forcement son parrain. => Le parrain peut nous reprocher de communiquer ses informations personnelles.
Commentaire de Justin Ziegler [ 03/févr./09 17:27 ]
1/ effectivement, on peut utiliser nepasrepondre@... plutot que mailer, je pense aussi que c'est mieux (sauf s'il y a des raisons de ne pas le faire). Au passage, on est justement en train de tenter de résoudre le pb d'anti-spam sur hotmail, et celui ci ne vient peut etre pas du mailer@... mais du return path et du from.

2/ on donne deja l'adresse du parrain, mais on le fait mal. Il s'agit de mieux le faire.

3/ Les widget parrainage ne sont pas concerné par les mails dont on parle ici.

OK ?
Commentaire de Cedric Favero [ 03/févr./09 17:36 ]
OK, si les widgets ne sont pas concernés c'est moins problematique.

En tout cas le nepasrepondre@priceminister.com est à privilégier pour le Reply-To , car il délivre une information particuliere à la personne qui essaye de nous contacter par ce biais.
Commentaire de Fabrice Feugas [ 03/févr./09 17:55 ]
En y réfléchissant, c'est vrai que ça me parait plus logique d'affecter une adresse @priceminister.com au reply-to car étant donné que l'utilisateur recevra un email de Price avec la charte price, s'il fait "répondre" il s'attendra à nous répondre et pas à répondre à son parrain.

En revanche, ça semble pertinent d'indiquer le nom du parrain dans le from en précisant que c'est "via priceminister". En reprenant les indications de Patrice : "Prénom Nom via PriceMinister" <mailer@priceminister.com>.

Oui les widgets parrainage ne sont pas concernés.
Commentaire de Swan Desportes [ 03/févr./09 18:03 ]
Gestion des messages --> TX
Commentaire de Justin Ziegler [ 03/févr./09 19:40 ]
Il y a une confusion.

Pour moi on s'oriente vers :

Return-Path: indique à quelle adresse doivent être envoyées les réponses automatiques du serveur (no delivery par exemple)
valeur: nepasrepondre@priceminister.com

Reply-To: indique l'adresse à laquelle une réponse éventuelle du destinataire va être envoyé (quand on clique sur Répondre dans outlook par exemple).
valeur: l'adresse du parrain (sauf contre indication technique)

From: ce qui apparaîtra si on regarde le mail avec Outlook ou un webmail. Le format devrait être:
"Prénom Nom" <nepasrepondre@priceminister.com> avec "Prénom Nom" qui peut être ce que vous voulez.
Commentaire de Fabrice Feugas [ 04/févr./09 09:54 ]
Oui, et ça ne risque pas d'être confusant pour l'utilisateur de voir qu'il reçoit un email de PriceMinister et de répondre à quelqu'un d'autre quand il fait "répondre" ?

On peut imaginer que s'il voit du PriceMinister dans le from, s'il fait répondre, il pensera s'adresser à nous avec des questions pour le SAV... Si c'est le parrain qui reçoit ces questions, on met un intermédiaire en plus et on risque de brouiller les esprits. Au final c'est le SAV qui devra tout démêler.
Commentaire de Cedric Favero [ 04/févr./09 11:10 ]
Pour moi le filleul n'a aucune raison de contacter le parrain en direct effectivement.

S'il veut faire reply , il doit tomber sur nepasrépondre@priceminister.com qui va lui délivrer un message convivial et détaillé ;-)

Par contre , pas de souci à faire apparaitre Prénom Nom via PriceMinister.
Commentaire de Justin Ziegler [ 04/févr./09 18:57 ]
il y a parfois des parrains abusifs...

je trouve que c'est potentiellement intéressant que le filleul puisse faire un reply au parrain pour lui dire "lache moi la grappe".
en fait j'y vois meme une réduction du travail de l'équipe SAV qui n'auront donc pas à traiter ces cas.

la limite, c'est que les gens risquent de s'insulter...
et que du coup le SAV n'est pas mis au courant de l'abus qui concerne peut etre aussi d'autres filleuls.

L'idéal pourrait être d'intégrer la notion de parrainage abusif en haut du mail de parrainage ?
un truc du genre : "si vous ne connaissez pas xxxx_le_parrain : vous pouvez signaler un parrainage abusif"
Commentaire de Cedric Favero [ 04/févr./09 19:13 ]
Mon idée en tant que paranoiaque du SAV , c'est éviter qu'ils se contactent directement car on ne sait pas ce qu'ils peuvent fabriquer.
Toujours mieux qu'ils s'adressent à nous en cas de probleme.

Si tu veux qu'ils puissent nous contacter en cas de souci, on les envoie vers page contact.
Commentaire de Justin Ziegler [ 04/févr./09 19:34 ]
Bon, je retente la conclusion :

Return-Path: indique à quelle adresse doivent être envoyées les réponses automatiques du serveur (no delivery par exemple)
valeur: nepasrepondre@priceminister.com
==> risque de boucle de mail à cause de la config de reponse automatique ? Patrice ?

Reply-To: indique l'adresse à laquelle une réponse éventuelle du destinataire va être envoyé (quand on clique sur Répondre dans outlook par exemple).
valeur: nepasrepondre@priceminister.com

From: ce qui apparaîtra si on regarde le mail avec Outlook ou un webmail. Le format devrait être:
"Prénom Nom" <nepasrepondre@priceminister.com> avec "Prénom Nom" qui seront ceux du parrain !

on pourrait rajouter un "via PriceMinister" dans le from ?
Commentaire de Emeric Teil [ 01/avr./09 14:35 ]
Bloqué en attente de confirmation, cf. dernière commentaire de Justin...
Commentaire de Justin Ziegler [ 03/avr./09 18:13 ]
Patrice ?
Commentaire de Patrice Boulanger [ 07/mai/09 15:08 ]
Voici la conclusion que je propose:

 - Return-Path: peut être fixé à ce qu'on veut, mais pas à nepasrepondre@priceminister.com. On pourrait mettre mailer@priceminister.com, ça ne devrait pas poser de problème côté antispam, puisque ce n'est pas une adresse From, c'est juste utilisé pour faire un retour en cas de problème avec la délivrance du mail.

 - Reply-To: nepasrepondre@priceminister.com pour qu'une éventuelle réponse du filleul reçoive un message convivial et détaillé (dixit Cédric Favero)

 - From: on peut tout imaginer dans la partie entre guillemet mais l'adresse devra être "nepasrepondre@priceminister.com"

J'ai fait quelques tests, voici les résultat:

[root@baillet ~]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 vhq.babel.fr ESMTP 1.0
HELO tmp20
250 vhq.babel.fr
MAIL FROM: mailer@priceminister.com
250 2.1.0 Ok
RCPT TO: patrice.boulanger@priceminister.com
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: "Le nom du parrain via PriceMinister" <nepasrepondre@priceminister.com>
To: patrice.boulanger@priceminister.com
Subject: APP-24124
Reply-To: tartanpion@priceminister.com

Test.
.
250 2.0.0 Ok: queued as 93B61648006
QUIT
221 2.0.0 Bye

soit ici:

Reply-To = tartanpion@priceminister.com
From = "Le nom du parrain via PriceMinister" <nepasrepondre@priceminister.com>

Voir la capture d'écran en copie pour le résultat.


 
Commentaire de Patrice Boulanger [ 07/mai/09 15:27 ]
En fait, je pense qu'il serait souhaitable de pouvoir modifier ces adresses facilement, par exemple en utilisant des propriétés JBOSS. Ca serait mieux si on s'aperçoit qu'une adresse se trouve blacklistée soudainement.

Est-ce que c'est possible ?

Patrice.

Commentaire de Nicolas Chauveau [ 07/mai/09 17:45 ]
OK

Sur le principe on défini 3 prop applicatives pour que l'exploitation puisse définir les valeurs
 - from
 - reply-to
 - return-path
par défaut.

TODO fonc : Vérifier si cela s'applique à tout type de mail (automatiques, BO ...)

Commentaire de Justin Ziegler [ 07/mai/09 17:49 ]
non, cela ne s'applique pas directement à tout type de mail.

on doit pouvoir positionner une valeur par défaut pour chaque paramètre applicable à tous les type de mail.
(on lui donnera la valeur actuelle)

en plus on veut pouvoir préciser une valeur spécifique d'un paramètre, type de mail par type de mail.
Commentaire de Cedric Favero [ 07/mai/09 17:50 ]
Euh là on ne parle que des mails parrainage , n'est-ce pas?
Commentaire de Patrice Boulanger [ 14/mai/09 15:49 ]
On ne parle en effet que des mails de parrainage. Qui plus est, ce qu'il faut modifier est le comportement incorrect de l'application lorsqu'elle envoie des mails de parrainage, ce n'est pas le cas pour les autres mails applicatifs.

En résumé:

- 1 seule propriété pour le Return-Path. Personnellement, je pense que cette propriété pourrait être globale à tous les mails applicatifs
- 1 propriété uniquement pour le parrainage qui va indiquer l'adresse utilisée dans le champ "From:"
- Modifier l'appli pour qu'elle utilise la propriété ci-dessus dans les mails de parrainage pour le "From:" ("Prénom Nom via Priceminister" <l'adresse ci-dessus>) et la commande SMTP "MAIL FROM:".
- Le champ "Reply-To:" n'est pas utile si on est d'accord que l'adresse utilisée pour une réponse manuelle de la part de l'utilisateur sera la même que pour le "From:", on pourrait donc le supprimer.

Commentaire de Nicolas Chauveau [ 28/mai/09 18:06 ]
Cela devient critique pour le marketing (perte de vitesse du parrainage). cf OSZ.

Voir avec PBO pour bien traiter le sujet.
Commentaire de Patrice Boulanger [ 09/juin/09 17:12 ]
Salut le pôle contenu,

Pour appuyer le dernier commentaire, pouvez-vous nous donner la planification pour la correction de ce bug?

Merci.
Patrice.
Commentaire de Fabrice Feugas [ 10/juin/09 14:08 ]
Pour reprendre la réponse faite par email, on est parti sur une mise en prod en CTN-L, la semaine prochaine.
Commentaire de Justin Ziegler [ 10/juin/09 14:45 ]
voila une très bonne nouvelle !
pourrait on avoir un aperçu de la solution ?
Commentaire de Damien Dorizy [ 10/juin/09 19:00 ]
La correction consiste à utiliser non plus l'email du parrain, mais le mail utilisé par défaut dans le message type correspondant. Par ailleurs, le nom de l'utilisateur est remplacé par un label Infoglue : "Prénom Nom via PriceMinister".
Pour le Return-Path, il sera défini dans le mail-service.xml.

Ce qui donne :
Return-Path : mailer@priceminister.com
From : "Prénom Nom via PriceMinister" <nepasrepondre@priceminister.com>
Reply-To : "Prénom Nom via PriceMinister" <nepasrepondre@priceminister.com>

Plus d'infos dans le Wiki sur ce qui est fait et ce qu'il faudrait faire dans l'idéal : http://pricewiki.lan/Wiki.jsp?page=AdressesSourcesDesMails

Le dév est fait, la solution devrait être opérationnelle en integ demain matin (jeudi 11/06).
+ des scripts restent à passer pour modifier le mail par défaut dans la table brand (voir APP-25575)
Commentaire de Damien Dorizy [ 11/juin/09 12:19 ]
C'est ok en integ
Commentaire de Justin Ziegler [ 11/juin/09 20:25 ]
si demain on souhaite changer cela, est ce que c'est paramétrable ?
Commentaire de Damien Dorizy [ 12/juin/09 09:05 ]
Oui, pour les différents éléments :
- L'adresse email du From et Reply-To est celle définie par les message-type parrainage en BO : il suffit donc de la changer en BO, et il est possible de la modifier pour un message en particulier.
- Le label "Prénom Nom via PriceMinister" est défini dans Infoglue.
- Le return-path est lui configuré de manière globale, modifiable par l'exploit mais pour tous les mails en même temps.




[APP-23828] Surveillance vendeur - regle surveillant nbs de ventes committed par rapport aux ventes reçues Création: 02/janv./09 17:56  Mise à jour: 28/juil./09 15:44  Résolue: 21/juil./09 12:16

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 50.0.1

Type: Amélioration Priorité: Mineur
Rapporteur: Cedric Favero Attribution: Dispatcher (Pôle TX)
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Pays:
FRA - France
Projets PM: *** RESERVE ***

 Description   
On a une règle de surveillance vendeur qui fait passer le compte en visibilité -1 lorsque le compte a un nombre d'articles committed >30 et 0 ventes reçues.

Cette regle est actuellement "en dur" et non pas en mot-clé.

La demande serait de savoir si on pouvait la "récupérer" en mot clé velocity afin de pouvoir la rendre plus flexible ?
Celà nous permettrait de gérer plsu finement par type de produit et faire des exclusions.

Merci.


ex d'un compte ayant matché cette regle:
http://bo.priceminister.jmh/user_back?action=userview&showeventothers=true&useraccountid=12978117


 Commentaires   
Commentaire de Emeric Teil [ 26/janv./09 16:32 ]
Arnaud, je te laisse voir si on peut répondre "facilement" à cette question ou bien s'il faut intégrer cela à un projet CoSAV. Merci
Commentaire de Arnaud Forgues [ 01/avr./09 11:04 ]
A faire en Chasse, au moins pour la réponse à la question et si c'est simple à faireà boucler en chasse également, sinon retour à dispatcher TX pour priorisation dans un CoSAV
Commentaire de Cedric Favero [ 21/juil./09 11:24 ]
Comme vu à l'époque avec Emilien lors du projet "surveillance vendeurs PRO" , ce mot clé est en dur dans l'appli et est testé lors du passage du batch panier.
Il n'a donc pas été possible de le récuperer au niveau de la surveillance vendeurs.

Suite à TX-H , il fonctionne à présent aussi pour les comptes en visibilité 2 mais si on veut le parametrer plus finement, çà passera par une demande spécifique.

Dans l'attente , on met en place des rapports BI pour détecter les choses qui nous interessent.
Commentaire de Arnaud Forgues [ 21/juil./09 11:35 ]
Je renvoie donc la demande chez Dispatcher Pole TX pour précision du besoin puis priorisation via CoSAV
Commentaire de Emeric Teil [ 21/juil./09 12:16 ]
Inutile donc de conserver ce Jira, la demande, si toujours d'actualité, entrera dans le fichier CoSAV.




[APP-23783] Intégration du statut d'auto-entrepreneur Création: 22/déc./08 17:26  Mise à jour: 03/avr./09 12:12  Résolue: 27/mars/09 15:48

Etat: Fermé
Projet: Application PriceMinister
Composants: Compte utilisateur
Affecte la/les version(s): 36.1.0
Version(s) corrigée(s): 44.0.0 (TX-F)

Type: Amélioration Priorité: Majeur
Rapporteur: Benoit Tabaka Attribution: Dispatcher (Traduction)
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File page_item_bo.jpg     JPEG File page_user_bo.jpg     JPEG File propal.jpg    
Liens des demandes:
Duplicate
doublon de APP-23883 [COSAV] Avoir une distinction en BO p... Fermé
Pays:
FRA - France
Site: Prod
Projets PM: *** RESERVE ***

 Description   
Il s'agit de procéder à des modifications du F.O. pour intégrer le statut d'auto-entrepreneur qui entre en vigueur le 01.01.2009

L'auto-entrepreneur aura 1 numéro d'immatriculation (SIRET)
L'auto-entrepreneur n'aura pas de raison sociale + aura le même régime que le micro-entrepreneur (non récupération de la TVA).

Il s'agit ici de modifier le F.O. pour indiquer aux gens qu'ils peuvent s'inscrire :
- à titre professionnel (et non comme une société)
- qu'ils doivent cliquer sur le bouton "micro-entreprise" s'ils sont auto-entrepreneur.

le champ raison sociale sera obligatoire (ce qui normalement ne doit pas l'être), mais finalement on se passera de cela (et on leur dira d'indiquer dedans qu'ils sont auto-entrepreneur).

En PJ, ce que cela pourrait donner.


 Commentaires   
Commentaire de Emeric Teil [ 22/déc./08 17:49 ]
Benoît :
-> Les micro-entreprises sont-ils censés avoir une raison sociale ?

Si ce n'est pas le cas, on peut éventuellement envisager de ne plus proposer ce champs si l'option "ME ou AE" est sélectionnée.
Commentaire de Benoit Tabaka [ 22/déc./08 17:57 ]
Bonne Question Emeric. Je viens de rechercher.

Une micro-entreprise "ne peut pas être une société, il s'agit obligatoirement du statut juridique de l'entrepreneur individuel". Donc, si une micro-entreprise n'est pas une société, cela veut dire qu'elle n'a pas de raison sociale (terme réservé aux SA, SARL, EURL, etc.)

Donc, effectivement, si ME/AE est sélectionné, on peut décider de masquer le champ "Raison sociale".
Commentaire de Emeric Teil [ 22/déc./08 18:31 ]
Dernière question :
-> Est-on sereins sur le fait qu'on ne pourra pas distinguer AE et ME ?
Commentaire de Benoit Tabaka [ 22/déc./08 18:34 ]
Emma nous a indiqué que les commerciaux mentionneraient dans 4d le fait que l'utilisateur est AE, si nécessaire on pourra donc les retrouver.

En outre, certaines règles de gestion vont aussi être adoptées d'un commun accord entre les commerciaux et le BO pour faire attention à ces nouveaux "pro".

Enfin, en toute logique économique, les micros-entrepreneurs devraient disparaître pour être AE vu que le régime est meilleur !
Commentaire de Cedric Favero [ 23/déc./08 09:22 ]
" Est-on sereins sur le fait qu'on ne pourra pas distinguer AE et ME ? "

Je repondrais par une question moi meme.
 A-t-on un moyen simplte de les indentifier en base sans gros dev?
Savoir si on pourrait les retrouver dans BI ou faire des regles de mots clés particulieres..
Car à terme , une indication dans le compte ou dans 4D s'averera certainement insuffisante...

Mais si celà a un impact plus large, on verra dans un second temps..
Commentaire de Emeric Teil [ 23/déc./08 11:27 ]
C'est possible, cependant il y aura du Dev supplémentaire, et cela ne pourra intégrer le Projet TVA (actuellement, "Auto-Entrepreneur") est sorti de la RoadMap TX, en accord avec le CoEx.
Commentaire de Emeric Teil [ 24/mars/09 16:44 ]
OK donc pour conclure, deux choses :
-> Modifier le label Front Office : "Je déclare bénéficier du régime fiscal de « micro entreprise « ou être déclaré « auto-entrepreneur « et ne pas posséder de N° de TVA Intracommunautaire. "

-> En BO, sur les pages User et Item, ajouter, à côté du wording "PRO" la mention "EI" si le compte isMicroCompagny
Commentaire de Fabien Bourdoulous [ 24/mars/09 18:43 ]
Labels à publier dans IG :
/default/Labels/_Mon Compte/_Espace Vendeur/SellerProfileProCompanyInclude/info_precise_micro_company_status - French (French) (274660)

Est-ce que la modification du label concerne aussi ES et UK ? Dans ce dernier cas, demander les traductions.

Commentaire de Fabien Bourdoulous [ 25/mars/09 11:46 ]
Label à traduire en UK & ES :

/default/Labels/_Mon Compte/_Espace Vendeur/SellerProfileProCompanyInclude/info_precise_micro_company_status - French (French) (274660)
Commentaire de Rocio Perez-Garcia [ 26/mars/09 13:00 ]
Ajouté "auto-empresario" à la traduction espagnole.
Commentaire de Rémi Virlouvet [ 26/mars/09 13:03 ]
auto-entrepreneur sur UK

fait sur cms 1




[EXP-4604] Mailing vers les pros pour inciter à mettre le compte en vacances si absent pour la période de Noël Création: 05/nov./08 12:36  Mise à jour: 17/nov./08 09:47  Résolue: 12/nov./08 09:54

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Gaël Seguillon Attribution: Patrice Boulanger
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word Cher partenair1.doc     Microsoft Word Cher partenaire.doc    
Pays:
FRA - France

 Description   
Pour la période des fêtes de fin d'année comme pour les grandes vacances il faut adresser à toute notre base de pros actifs un mail les invitant à se mettre en vacances. en pj le mail à en voyer foramt txt et html
n'hésitez pas à me contacter si vous avez besoin de plus d'infos
merci
Gaël



 Commentaires   
Commentaire de Patrice Boulanger [ 12/nov./08 09:54 ]
C'est pas l'exploit qui envoie ce genre de mail, à voir plutôt avec le BI. Ce genre de mail doit être envoyé via 1000Mercis.

Merci.
Commentaire de Patrice Boulanger [ 17/nov./08 09:47 ]
Question:

Salut Patrice,
Je reviens vers toi concernant ma demande http://pricejira.lan/browse/EXP-4604
En fait j'avais vu ça avec le marketing avant et c'est eux qui m'ont assuré la possibilité de cet envoi par l'équipe d'exploit, l'idée était justement de ne pas passer par 1000 mercis car pour un mailing vers 3000 personnes il vont nous facturer au moins 300 euros.
Merci

Gaël

Réponse:

Le fait que 1000Mercis fasse payer ce genre de prestation n'est pas étonnant, ils ont des accords avec les opérateurs pour réaliser ce genre d'envoi massif afin de ne pas se faire blacklister. Ce n'est pas notre cas. On ne va pas risquer de faire blacklister nos mailers (au bureau ou, pire, sur la plateforme de prod) pour 3000 mails.

Enfin, nous n'avons pas les outils nécessaires pour faire cela.

Donc, il faut passer par 1000mercis.

Patrice.




[CAT-1860] Problème frais de port associés aux livres Création: 06/juil./09 11:32  Mise à jour: 04/sept./09 09:41  Résolue: 04/sept./09 09:41

Etat: Résolu
Projet: Paramétrage - Non Import
Composants: Frais de port
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Critique
Rapporteur: Xavier Fabregat Attribution: Rocio Perez-Garcia
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg    
Liens des demandes:
Similaire
similaire à APP-21918 L'acheteur ne peut pas choisir entre ... Fermé
Pays:
ESP - Espagne

 Description   
Des nombreux livres sont associés à la taille 7 (donc transaction en mode d'envoi "normal" interdite.

Apparemment le souci est lié au poids de l'article car on trouve toute sorte de livres (BD, litterature, Beaux-arts,...) , de toutes les tailles (grand format, moyen,...) et soumis à partir du Front office ou par fichier d'import.

Si le livre n'a pas de poids ou si celui-ci est supérieur à 1kg, il passe en T7 automatiquement

Exemples:

http://bo.priceminister.es/referential_back?action=productview&productid=22087649

http://bo.priceminister.es/referential_back?action=productview&productid=46632233

Merci









 Commentaires   
Commentaire de Emeric Teil [ 09/juil./09 16:53 ]
Voir Arnaud si questions sur le bon paramétrage à effectuer...
Commentaire de Marion Anfreville [ 10/juil./09 15:17 ]
ATTENTION : bien prévenir l'équipe d'exploitation (Eric Vannier pour les flux partenaires) + le market + l'équipe BI (Agathe) si changement dans les frais de port.

Il peuvent avoir à faire des adaptations pour prendre en compte les modifications apportées.
Commentaire de Julien Sananikone [ 04/août/09 11:23 ]
essaye de voir ce qui se passe et tiens moi au courant
Commentaire de Rocio Perez-Garcia [ 06/août/09 12:06 ]
Dans la MeV FO, le problème est lié au paramètrage des fdp pour les livres. On prend en compte pour les déterminer : le poids, le format, la taille et le prix.
Mais pour le format tous les valeurs ne sont pas paramètres. Si dans la MeV on choisi un valeur qui n'est pas dans l'arbre, il passera automatiquement dans la T(7).
Sur la FR, le format comprend seulement les valeurs Grande, Moyen et Petit (pris en compte en Es dans Taille). Je propose désactiver le n¿ud Format en Espagne pour les Frais de Port et prendre en compte trois paramètres comme sur la France.
 Qu'en pensez vous ?

Commentaire de Rocio Perez-Garcia [ 12/août/09 18:01 ]
Dans le cas du Jira APP-21918, il a pris en compte le Format (álbum) et pas la taille (moyenne).
Ce problème peut être résolu comme dit précédemment.
Par contre, si on veut autoriser l'envoi en Normal pour les livres de plus d'un kilo, ce serait plus simple de créer une nouvelle taille de frais de port.
A voir et discuter entre les équipes pertinents.
Commentaire de Gaël Seguillon [ 19/août/09 14:59 ]
Vu avec Rocio on passe à un système différent pour contourner le problème
On se base sur le système du site Fr
Seul le champ poids détermine le remboursement du port, le format ou type de livre n'est plus pris en compte sur l'attribution d'un remboursement de frais de port.

On rajoute dans le formulaire de soumission un champ poids
petit = jusqu'à 350 g
moyen de 350 à 1000 g
grand au dessus de 1000 g (1 kg)

On rend le champ format/type de livre facultatif lors de la mise en vente.

Quand le poids n'est pas renseigné on met par défaut le poids moyen

merci

Gaël
Commentaire de Aurélien Vergalli [ 19/août/09 15:31 ]
Gael : "On rajoute dans le formulaire de soumission un champ poids"
=> CAD préciser les 3 plages de poids correspondant aux 3 tailles de la droplist "Tamaño" du formulaire, comme en FR, c'est bien ça ?

Gael : "Quand le poids n'est pas renseigné on met par défaut le poids moyen"
=> concerne les imports avec poids et taille non renseignés ?
Commentaire de Rocio Perez-Garcia [ 19/août/09 18:27 ]
L'idée est:

- Désactiver le n¿ud "Type d'ouvrage" comme paramètre pour déterminer les frais de port et adapter le formulaire MeV avec les plages de poids comme sur FR.

Eric nous confirmera pour le flux partenaires avant de le réaliser.
Commentaire de Gaël Seguillon [ 20/août/09 11:57 ]
Pou répondre à Aurélien
oui ça concerne les imports pour la partie soumission en front il faut laisser le choix de la catégorie de poids obligatoire
ok là dessus ?
Commentaire de Aurélien Vergalli [ 21/août/09 09:37 ]
Ok pour moi.
Commentaire de Eric Vannier [ 01/sept./09 14:56 ]
pour résumer :

Pour déterminer les frais de port d'un livre, il faut :

le poids => PAS OBLIGATOIRE déterminé dans ce cas par la taille
la taille

le prix => permet en france de savoir si on passe en recommandé... est-ce que pour l'espagne on a un équivalent ou bien le prix n'est pas utile ?

C'est ça ?

Commentaire de Rocio Perez-Garcia [ 01/sept./09 15:03 ]
Merci Eric, oui c'est ça. Alors pour le prix, comme on a déjà discuté, on conserve le paramètrage actuel, c'est à dire:

Petit : moins de 12.2 (T.190)
Moyen : Entre 12.2 et 45.73 (T.4.60)
Grand : Plus de 45.73 (T.7)
Commentaire de Rocio Perez-Garcia [ 02/sept./09 09:28 ]
Fait en preview (et testé en Integ).

- Désactivé le noeud dans les frais de port qui prenait en compte le Type d'ouvrage pour le calcul.
- Modification des valeurs "taille" dans le formulaire Mise en Vente FO, pour préciser les plages de poids selon la taille.

Merci à tous !




[IMP-3870] profil partenaire : intellishop Création: 29/juin/09 17:12  Mise à jour: 30/oct./09 15:44  Résolue: 13/août/09 11:31

Etat: Résolu
Projet: Paramétrage - Import
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Skender Berisha Attribution: Jérome Marianne
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel intellishop.xls    
Pays:
FRA - France
Login: intellishop
Séparateur: Point-virgule (;)
Type de traitement:
Mise à jour/création annonces avec mise à jour/création produits (écrasement)

 Description   
Bonjour

Serait-il possible d'enlever le modèle neteven avec ce partenaire, il ne travaille plus avec eux.

Merci de lui remettre un profil de FTP standard : gestion flux de commande + import de stock.

je lui ai fait un export de son stock, il aura comme ça les id product price.

Merci

Skender

 Commentaires   
Commentaire de Frédéric Nahum [ 30/juin/09 10:29 ]
il me faut le fichier car sinon je ne peux pas connaitre l'ordre des colonnes
Commentaire de Skender Berisha [ 30/juin/09 10:34 ]
je lui ai fai un export de stock bi, il va se servir de ce fichier ça te convient ?

Merci

Skender
Commentaire de Jérome Marianne [ 16/juil./09 18:13 ]
Avec ce fichier le pro ne pourra faire que la création annonces.

Pour créer des produits il faudra qu'il utilise le modèle "accessoire audio vidéo".

Commentaire de Jérome Marianne [ 06/août/09 17:52 ]
Le format Neteven à été retiré.

Le pro peut-il utiliser un de nos formats pour la mise à jour?
Commentaire de Frédéric Nahum [ 12/août/09 16:39 ]
ou en est cette demande ???
Commentaire de Jérome Marianne [ 13/août/09 11:31 ]
Le format Neteven à été enlevé.

Les formats "Vêtements" et "bouquiniste" qui étaient paramétrés dans le compte ont été passés en écrasement.

Le flux de commande était déjà paramétré dans le FTP.

Concernant les annonces Accessoires High Tech, il faut donner au pro le format minimaliste et ouvrir un nouveau JIRA pour le paramétrage.




[BIN-621] [CRM achat] : Création d'un rapport sur paniers abandonnés Création: 31/juil./09 11:31  Mise à jour: 29/janv./10 09:29  Résolue: 30/déc./09 09:54

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Julien Meraud Attribution: Dalila Belkebir
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Nous utilisons actuellement un rapport disponible dans mon perso sur ur marketing qui nous donne le nombre de paniers abandonnés et le nombre de membres ayant abandonné un panier.

Nous venons de nous rendre compte que la jointure naturelle entre la table purchase et user diminue énormément le nombre de paniers abandonnés (seuls sont pris en compte les paniers des abandonnistes loggés j'imagine)

Nous lançons actuellement beaucoup d'actions sur abandonnistes non loggés et nous souhaiterions construire un rapport donnant par jour, le nombre de paniers abandonnés, le nombre d'abandonnistes (il suffit de reprendre le rapport existant et de faire une jointure externe) avec un split par loggés/non loggés (en fonction de l'existence d'un nom dans la table purchase) plus un 2e onglet avec un split par catégories (pas de split loggés/non loggés ici)

Je suis à votre disposition en cas de demande,

Julien

 Commentaires   
Commentaire de Dalila Belkebir [ 30/déc./09 09:54 ]
Bonjour,

La demande est livrée sur les plateformes France, UK & ESPAGNE.
Vous y trouverez donc :

- Dans le répertoire existant Purchase
- Un nouveau rapport « Monthly purchase activity »
Ce rapport a pour objectif le suivi des paniers aux différents stades de son cycle de vie: paniers abndonnés, autorisés, capturés.
Ces indicateurs sont suivis par mois de création du panier, et répartis sur trois onglets: nombre total de paniers,
paniers standards et paniers négociés.

Pour plus d'informations sur le BI, nous vous invitons à consulter les spécifications :
T:\BI\00 - Projets\2009-10 Monthly purchase activity

Nous attendons donc vos retours pour validation du rapport et des droits users.

Cdlt,
Dalila.
Commentaire de Julien Meraud [ 28/janv./10 14:01 ]
OK pour moi,

Merci.




[BIN-609] [Marketing] : Mailings partenaires Espagne : demande d'extraction de la base Création: 08/juil./09 17:19  Mise à jour: 26/janv./10 17:38  Résolue: 02/déc./09 11:29

Etat: Fermé
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Charles Decaux Attribution: Julien Girardet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Document(1).xls     PNG File ko - avec delivery.png     PNG File ok - no delivery.png     JPEG File Requete.jpg    
Pays:
ESP - Espagne

 Description   
Hello,

comme discuté avec Agathe, voici un brief afin de créer un rapport permettant d'extraire les opt-in partenaires de la base Espagne.

CONTEXTE
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Aujourd'hui, nous utilisons 1000Mercis pour envoyer des mailings partenaires à nos opt-in partenaires. Cela génère des revenus importants, mais pose plusieurs problèmes :
- cela nuit à la réputation des envois "priceletter" sur la France et l'Espagne
- cela coûte cher, puisqu'à chaque envoi, 1000Mercis réclame 230¿. Ainsi nous dépensons plus de 2300¿ par mois pour faire des mailings partenaires. C'est trop cher.

C'est pourquoi nous souhaitons arrêter de travailler sur ce sujet avec 1000mercis
Nous voulons utiliser, uniquement pour les mailings partenaires, une autre solution (à priori e-circle) que Nerea maîtrise bien.

OBJECTIF
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Pour travailler avec e-circle, nous devrons uploader avant chaque envoi, la liste des adresses emails dans la base priceminister.es

Ainsi, nous souhaiterions la création d'un rapport qui nous fournisse la base de données au format CSV répondant au ciblage suivant :
- opt-in partenaires
- ayant un compte OU étant un contact contactable. Il est très important que nous ayons bien les contacts contactables car ceux-ci représentent une majorité dans la base de donnée.
- email unique : si on peut éviter d'avoir plein de fois le même email ce serait bien.

Concernant le contenu de la base de données, nous souhaiterions, dans un monde idéal, disposer de tous les champs suivants. J'ai cependant précisé ceux qui avaient un caractère obligatoire et ceux qui sont facultatifs. Attention, obligatoire ne veut pas dire qu'il ne faut pas mettre le contact/compte si on n'a pas l'info. Obligatoire veut dire qu'on souhaite intégrer l'information si on en dispose.

- Nom (obligatoire)
- Prénom (obligatoire)
- userid (obligatoire pour désabonnement)
- email (obligatoire)
- login (facultatif)
- civilité (facultatif)
- année de naissance ou âge (facultatif)
- pays (facultatif)
- ville (facultatif)
- code postal (facultatif)
- est actif (acheteur ou vendeur) ? (facultatif)
- date d'arrivée dans la base (facultatif)

DELAIS
---------------------------------------------------------------------------------------------------------------------------------------------------
Nerea est en congés tout le mois de juillet. Si on arrive à mettre en oeuvre ce rapport fin juillet/début août ce serait top

AVANCEMENT
---------------------------------------------------------------------------------------------------------------------------------------------------
J'ai tenté de faire un rapport, mais j'ai peur qu'il ne contienne pas les contacts contactables. J'ai le sentiment qu'il ne contient que les mails des comptes. Voici l'adresse de ce rapport Mes Dossiers > Favoris > Charles > Opt in partenaires Spain

Merci !!!!!!!

 Commentaires   
Commentaire de Charles Decaux [ 21/juil./09 12:01 ]
Hello,

j'ai crée un rapport. Il se trouve dans Mes Dossiers >> Favoris >> Charles >> Extraction de la base opt-in partenaires

Dans ce rapport j'ai demandé les champs suivants :
- user first name
- user last name
- user account id
- user email address
- user login
- user title label
- user birth date
- user address country name
- user address city
- user address zip
- purchase count (afin de savoir s'il est acheteur ou non)
- seller activation date (afin de savoir s'il est vendeur ou non)

J'ai ajouté un filtre sur le subscription pour n'avoir que ceux qui sont abonnés aux news partenaires.
J'obtiens des résultats.

J'ai plusieurs problèmes.
1. Il ne me sort pas les contacts contactables qui n'ont pas de compte. Je n'arrive pas à comprendre pourquoi.
2. Il ne me sort que les comptes ayant effectué au moins un achat
3. Il ne me sort que les comptes où le vendeur est actif

Du coup, la liste est fortement restreinte et le rapport ne correspond pas à mon besoin. J'ai mis les résultats en pièce jointe/
Comment faire pour avoir des résultats corrects ?

Merci de votre aide


Commentaire de Julien Girardet [ 27/juil./09 15:59 ]
Salut Charles,

A propos de tes questions :
En utilisant l'indicateur "Purchase count" tu auras seulement les comptes acheteurs, et donc tu n'auras pas les contacts
Si le but de "purchase count" est de savoir si le compte est acheteur ou pas, je te propose d'utiliser la dimension "First purchase authorization date".
Ainsi en fonction de sa valeur (renseigné ou null) tu sais si le compte est acheteur ou pas.

Par contre, tu ne peux pas avoir l'info si le user est vendeur en utilisant "seller activation date", ca ne marche pas. Tu es obligé de supprimer cette dimension de ta requete sinon tu filtres uniquement les vendeurs.

Enfin, il faut ajouter une condition pour obtenir uniquement les comptes actuellement abonnés aux mails partenaires (sinon tu as aussi les désabonnés)
Pour ca, tu utilises le filtre "Active subscription" dans la classe "Mail subscription"

Concernant l'email unique, tu ne peux pas avoir un email unique si tu veux dans ton rapport le userid et le nom/prénom. Pour un email peut correspondre plusieurs userid et nom/prénom...
Pour info, j'ai fait quelques comptages sur ceux qui sont abonnés aux mails partenaires et qui ont plusieurs comptes pour un meme mail :
- 2142 mails correspondant à des multi comptes, soit 4547 comptes


En résumé je te propose la requete suivante :
- user first name
- user last name
- user account id
- user email address
- user login
- user title label
- user birth date
- user address country name
- user address city
- user address zip
- First purchase authorization date

Avec comme filtres :
- Select subscription type
- Active subscription

A la date d'aujourd'hui j'obtiens 153307 comptes correspondant aux critères.

A ta dispo, si tu as des questions.

Julien.
Commentaire de Charles Decaux [ 28/juil./09 12:19 ]
Hello Julien,

merci beaucoup pour ton aide, ça va vraiment nous faire faire de belles économies !

Concernant le comptage, 1000 mercis envoie les emails opt-in partenaires à 136 698 emails
Alors que toi tu indiques 153 307 comptes avec 4547 comptes qui ont la même adresse.

L'écart est donc assez important, est-ce qu'on sait pourquoi ?

Merci
Commentaire de Julien Girardet [ 28/juil./09 14:37 ]
Salut Charles,

Quelques pistes pour expliquer l'écart :
- les comptes ayant la meme adresse mail. (mon comptage est par compte alors que 1M est par email)
- les emails invalides chez 1M
- les boucles de rétroaction
- les pros (est ce que 1M envoie aux Pro ?, ils sont compris dans mon comptage)

Commentaire de Agathe Remy [ 17/août/09 11:26 ]
Bonjour Charles,

Est-ce que tu valides cette demande ?

Merci.
Agathe
Commentaire de Charles Decaux [ 17/août/09 11:28 ]
oui c'est parfait.
Merci bcp
Commentaire de Agathe Remy [ 17/août/09 11:35 ]
Merci!
Commentaire de Julien Girardet [ 26/août/09 11:34 ]
Bonjour Charles,

Suite a la refonte de la gestion des adresses dans BI (livré hier), ton rapport "Extraction de la base opt-in partenaires" ne peut plus fonctionner.

Tu utilises dans ce rapport plusieurs dimensions qui n'existent plus dans l'univers USER ACCOUNT :
- user address country name
- user address city
- user address zip

Ces dimensions correspondaient à l'adresse d'un user par défaut.


Aujourd'hui les dimensions adresses sont dans la classe "User address". Un user peut avoir plusieurs adresses, pour les différencier il faut utiliser le "User address type code/label" :
10 DELIVERY Livraison
20 PAYMENT Paiement
30 GAME Jeu
40 CUSTOMER_SERVICE SAV
50 SELLER_CONTACT Contact vendeur
60 BUYER_CONTACT Contact acheteur
70 PICKUP Enlevement
80 RETURN Expedition


En conclusion il faut prendre les dimensions dans la classe User address :
- user address country name
- user address city
- user address zip

Et choisir un type d'adresse en filtre. Je te conseille l'adresse de livraison, c'est surement la plus renseignée.
Donc par exemple "User adress type code = 10" dans la partie filtre de ta requete.

N'hesites pas a venir nous voir si tu as des questions.

Julien.
Commentaire de Charles Decaux [ 03/sept./09 14:22 ]
Salut Julien,

en fait j'ai un souci. J'ai mis dans les filtres user address type label= delivery
Le problème c'est qu'il me donne uniquement les account de users qui ont renseigné cette donnée.
Or, je voudrais également pouvoir obtenir les informations des comptes n'ayant pas renseigné cette donné.

Sais-tu comment je dois procéder ?

Merci
Commentaire de Julien Girardet [ 03/sept./09 14:38 ]
Salut Charles,

En effet, il faut ajouter une condition si tu veux les comptes n'ayant pas d'adresse de livraison.
Donc la condition doit être :

user address type label= delivery
OU
user address type label est null

ci joint un screenshot de la requete.

N'hesites pas a passer me voir si tu as besoin d'aide.

Julien
Commentaire de Julien Girardet [ 03/sept./09 14:38 ]
Requete BO
Commentaire de Charles Decaux [ 10/sept./09 15:06 ]
Salut Julien

En faisant un export de ma base, je me suis rendu compte qu'il manquait des comptes récents.

Par exemple, le compte kakily77 est bien optin partenaire dans le back office, mais n'apparaît pas dans les résultats de la requête.

J'ai testé sans mettre les filtres liés à l'adresse, et à ce moment là, cela m'a bien affiché le compte de kakily77

Peux-tu regarder ? Merci !

Commentaire de Agathe Remy [ 10/sept./09 15:06 ]
Bonjour Charles,

Est-ce que je peux fermer ce JIRA?

Merci.
Agathe
Commentaire de Charles Decaux [ 10/sept./09 15:06 ]
quand j'enlève les conditions de delivery, j'ai bien le compte kakily77
Commentaire de Charles Decaux [ 10/sept./09 15:07 ]
quand je remets les filtres delivery, je n'ai plus kakily77
Commentaire de Dalila Belkebir [ 21/sept./09 17:02 ]
Bonjour Charles,

Comme vu avec Agathe, est-ce que je peux fermer ce JIRA?

Merci.
Dalila.
Commentaire de Charles Decaux [ 24/sept./09 16:05 ]
hélas, non, on aimerait bien avoir la delivery address
c'est possible ?
Commentaire de Julien Girardet [ 27/nov./09 15:16 ]
Comme vu avec Charles, l'ajout de l'adresse de livraison est toujours d'actualité
Le rapport devra etre placé dans le repertoire de Benjamin (UR SALES).
Commentaire de Julien Girardet [ 02/déc./09 11:29 ]
Salut Charles,

Le rapport "Extraction de la base opt-in partenaires " avec l'adresse de livraison est dispo dans le repertoire de Benjamin (ur sales).

Julien.




[IMP-5813] PRO se plaint Commandes non transmises par FTP -Booksxpress Création: 16/avr./10 10:30  Mise à jour: 16/avr./10 13:42  Résolue: 16/avr./10 13:42

Etat: Résolu
Projet: Paramétrage - Import
Composants: Support entrant
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Daniel Pintamalli Attribution: Daniel Pintamalli
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: Booksxpress
Séparateur: N/A
Type de traitement:
N/A

 Description   
De : efim [mailto:efim@dvdlegacy.com]
Envoyé : lundi 29 mars 2010 20:58
À : daniel.pintamalli@priceminister.com; 'Gael Seguillon'; caroline.vallerey@priceminister.com
Cc : 'michael abitbol'; 'efim'
Objet : FW: Your account Priceminister
Importance : Haute

Bonjour Daniel,

Ce n'est pas la première fois nous n'avons pas reçu des commandes de priceminister.fr (compte: Booksxpress)
Pourriez-vous vérifier et corriger le problème.
Je prends toujours tous les fichiers placés dans le dossier \purchase
Je garde le fichier que j'ai pris dans mon 'history'; aussi que j'ai un fichier journal avec toutes les informations.

S'il vous plaît, donnez-moi les noms de fichiers où vous avez mis ces commandes:
84392718 25/03/2010-18:37 Nouvelle 2 articles
et
84450111 27/03/2010-01:45 Nouvelle 1 article

Merci,

Efim.

 Commentaires   
Commentaire de Daniel Pintamalli [ 16/avr./10 13:42 ]
Mail envoyé au pro:

De : Daniel Pintamalli [mailto:daniel.pintamalli@priceminister.com]
Envoyé : vendredi 16 avril 2010 13:42
À : 'efim'
Cc : 'michael abitbol'; 'Gael Seguillon'; 'param-imp@priceminister.com'; 'Jérôme Viviès'; 'Jeremy Pallot'; 'carlos.cantoni@priceminister.com'
Objet : Priceminister - booksxpres
Importance : Haute

Bonjour Efim,

On a constaté que certaines commandes que vous n'avez pas reçues par le biais du compte FTP, sont dues au fait que votre script récupère parfois le même fichier « purchase » 2 fois à la même heure, le 2ème écrasant le primer chez vous. Cela se produit parce que les fichiers s'appellent pareil quand il s'agit de la même heure.

Afin de contourner ce cas de figure il est nécessaire que votre script passe chercher vos commandes 1 fois par heure, entre la minute 45-50. Ainsi, vous n'aurez plus de commandes manquantes.


Cordialement,





[APP-29119] Suppression du tracking Automatisation Création: 12/avr./10 16:05  Mise à jour: 22/juin/10 10:01  Résolue: 03/mai/10 17:56

Etat: Fermé
Projet: Application PriceMinister
Composants: Tracking
Affecte la/les version(s): 66.0.1
Version(s) corrigée(s): 71.0.0 (CTN-R)

Type: Tâche Priorité: Majeur
Rapporteur: Julien Meraud Attribution: Alexandre Garnier
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File CTN-R_APP-29119_FR_update_ust_group.sql     Microsoft Excel RépartitionTrackingAutomatisation.xlsx    
Pays:
FRA - France
Site: Prod
Projets PM: *** CHASSE ***
Classif FONC: divers

 Description   
*** Pour Dispatcher CTN ***

Bonjour,

Le groupe de tracking Automatisation est devenu beaucoup trop complexe car il mélange de l'Achat, de la Vente et même un peu de fonctionnalités.

Nous avons donc créé de nouveaux groupes de tracking (CRM-Achat, CRM-Vente, CRM-Fonctionnalités, Test-Vente et Test-Achat) dans Xiti et le BO.

Il faudrait donc affecter les tracking du groupe Automatisation dans ces nouveaux groupes en respectant la classification présente dans le fichier xls en PJ.

Il y a aussi des codes présents dans d'autres groupes de tracking et qu'il faudrait affecter dans le groupe CRM-Fonctionnalités :

Groupe Actuel Nom du tracking Code
Default CRM_Memos 2242340
Parrainage Relance_ParrainsSansFilleuls 2013240
Parrainage reveil-FD 1824440
Parrainage relance-auto-FD 1824441

A partir de la création de ce JIRA, nous ne créerons plus de code de tracking dans le groupe automatisation mais dans les nouveaux groupes.

A votre disposition en cas de questions,
Julien


 Commentaires   
Commentaire de Fabrice Feugas [ 13/avr./10 15:17 ]
A faire sous forme de script (?).
Commentaire de Fabrice Feugas [ 14/avr./10 14:09 ]
Attention de bien se synchroniser avec le market au moment où vous traiterez ce JIRA. Merci d'aller voir Julien et Odile à ce moment et de valider avec eux toutes les modifications à venir.
Commentaire de Alexandre Garnier [ 03/mai/10 15:02 ]
Normal que dans le fichier Excel, il y ai des migrations de groupe vers :
* Parrainage (tracking 1490042[M15-parrain-avec-FAFD])
* PL-Mode (tracking 2279740[PL_IDKDO_0112])
* Marketing Communautaire (trackings 2292440[QuestionBlogOui] et 2292441[QuestionBlogNon])

??

Commentaire de Audrey Angleys [ 03/mai/10 15:06 ]
Salut Alexandre,

C'est normal en ce qui concerne le PL Mode (c'était une vieille erreur de groupe de tracking) et pour Marketing Communautaire.
Je laisse Carole répondre pour le parrainage.

Merci d'avance,

A ta dispo pour toute question.

Audrey
Commentaire de Carole Visser [ 03/mai/10 15:08 ]
C'est normal aussi pour le parrainage.

Merci

Carole
Commentaire de Alexandre Garnier [ 03/mai/10 17:08 ]
OK, c'était juste pour être sûr.

Le seul truc merdique c'est que je suis obligé de créer exactement les mêmes groupes en DEV et INTEG pour tester...
Commentaire de Alexandre Garnier [ 03/mai/10 17:44 ]
Au passage, je me posais quelques questions sur l'interface BO des codes et groupes de trackings :
* le lien de connexion XiTi est-il encore utile (de toute façon il ne fonctionne plus, on peut éventuellement le mettre à jour)
* les liens d'affichage des stats XiTi par groupe et par code sont-ils encore utiles (de toute façon ils ne fonctionnent plus, et ne peuvent plus fonctionner : APP-9590)
* les liens d'affichage des rapports par groupe et par code sont-ils encore utiles (amènent vers http://intra.priceminister.com/stats/reports/confid/Tracking_Reports/CRM-Achat/ alors que maintenant vous utilisez les rapports BI, non ?)
Commentaire de Alexandre Garnier [ 03/mai/10 17:49 ]
A priori OK : http://bo.ref-fr.pm.dev/tracking_back?action=ustgroupsearch&fuzzy=false&numberrows=100&startdate=03%2F04%2F2010 aux trackings inexistants en DEV près.
Commentaire de Alexandre Garnier [ 03/mai/10 17:55 ]
Les 127 premiers existent en DEV (jusqu'à "Post-Achat"), le reste non.

Pour cela, c'est bien OK en DEV.
Commentaire de Alexandre Garnier [ 03/mai/10 17:56 ]
[CAJ2010Q2CTN]
Commentaire de Carole Visser [ 04/juin/10 11:57 ]
OK pour moi concernant le groupe CRM fonctionnalité
Commentaire de Alexandre Garnier [ 04/juin/10 15:49 ]
Donc je rappelle : tous les trackings créés après l'été dernier n'existent pas en DEV, donc normal de ne pas les avoir ici.

Je vous indique quand ce sera OK en INTEG où ils devraient a priori tous exister.
Commentaire de Audrey Angleys [ 04/juin/10 15:53 ]
OK merci!
Commentaire de Alexandre Garnier [ 04/juin/10 17:19 ]
Vérifiable en INTEG : http://bo.pm.lan/tracking_back?action=ustgroupsearch&fuzzy=false&numberrows=100&startdate=03/04/2010




[APP-28836] Quamedia : Vérification/Mise à jour du tag + ajouts nouveaux codes de tracking Création: 19/mars/10 18:30  Mise à jour: 12/avr./10 11:44  Résolue: 09/avr./10 11:55

Etat: Fermé
Projet: Application PriceMinister
Composants: Infoglue, Tracking
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 66.0.1

Type: Tâche Priorité: Majeur
Rapporteur: Claire Genty Attribution: Carole Boucheny
Résolution: Corrigé  
Σ Estimation restante: 0 minutes Estimation restante: 0 minutes
Σ Temps consacré: 45 minutes Temps consacré: 45 minutes
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Quamedia tracking codes.xlsx     Text File Quamediagroup_Tag Eulerian.txt     Microsoft PowerPoint tag quamedia.pptx    
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-28985 Vérification du code / Adaptation Sous-tâche Fermé Carole Boucheny  
Pays:
FRA - France
Projets PM: *** A PLANIFIER ***
Classif FONC: comarket

 Description   
Bonsoir,

Nous allons lancer très prochainement une campagne Quamedia.

Une campagne de ce type a déjà été lancée.

Le tag Quamedia est-il encore présent? Si oui, il se peut qu'il faille le mettre à jour.
Ajout d'un paramètre donnant l'information sur le contenu du panier acheté. (pour optimiser le trafic).

Voici le nouveau tag à mettre en place/mettre à jour :

<!-- Eulerian Analytics - priceminister-fr / scartamount -->
<script type="text/javascript" src="http://qua.eulerian.net/ea.js"></script>
<script type="text/javascript">
/*<![CDATA[*/
EA_collector([
    'ref', 'REFERENCE_UNIQUE_DE_LA_COMMANDE'
   ,'amount', 'MONTANT_DE_LA_COMMANDE'
   ,'type', 'TYPE_DE_COMMANDE'
   ,'payment', 'TYPE_DE_PAIEMENT'
   ,'prdref', 'REFERENCE_PRODUIT_VENDU 1'
   ,'prdamount', 'MONTANT_UNITAIRE_PRODUIT_VENDU 1'
   ,'prdquantity', 'QUANTITE_PRODUIT_VENDU 1'
   ,'prdname', 'NOM_DU_PRODUIT_VENDU 1' /* optionnel */

   ,'prdref', 'REFERENCE_PRODUIT_VENDU 2'
   ,'prdamount', 'MONTANT_UNITAIRE_PRODUIT_VENDU 2'
   ,'prdquantity', 'QUANTITE_PRODUIT_VENDU 2'
   ,'prdname', 'NOM_DU_PRODUIT_VENDU 2' /* optionnel */

   ,'prdref', 'REFERENCE_PRODUIT_VENDU 3'
   ,'prdamount', 'MONTANT_UNITAIRE_PRODUIT_VENDU 3'
   ,'prdquantity', 'QUANTITE_PRODUIT_VENDU 3'
   ,'prdname', 'NOM_DU_PRODUIT_VENDU 3' /* optionnel */
]);
/*]]>*/
</script>
<!-- /Eulerian Analytics - priceminister-fr / scartamount -->

De plus, de nouveaux codes de tracking ont été créés au sein du groupe Quamedia.
Vous trouverez en pj tous les codes de tracking de ce groupe.

Il faudrait que le nouveau tag se déclenche pour tous les codes de tracking Ebay (cf. liste ci-après) :
2294340
2294341
2294342
2294343
2294344
2294345
2294346
2294347
2294348
2294349
2294350
2294351

Merci

Claire



 Commentaires   
Commentaire de Claire Genty [ 19/mars/10 18:31 ]
Codes de tracking Quamedia
Commentaire de Claire Genty [ 19/mars/10 18:31 ]
Tag Quamedia Eulerian Fourni
Commentaire de Marion Anfreville [ 25/mars/10 13:50 ]
J'ai planifié le paramétrage pour cette demande la semaine prochaine (S13) avec mise en prod S14 (à priori, le 08/04).
Commentaire de Carole Boucheny [ 30/mars/10 11:35 ]
Bonjour,

Je l'ai mis en place sur cms ref : http://www.ref-fr.pm.dev/info/home?t=2294340

Il semble que les variables suivantes ne soient pas récupérées :
   ,'type', 'TYPE_DE_COMMANDE'
   ,'payment', 'TYPE_DE_PAIEMENT'
   ,'prdname', 'NOM_DU_PRODUIT_VENDU 1' /* optionnel */

Exemple de ce que j'obtiens :

<!-- Eulerian Analytics - / scartamount -->
<script type="text/javascript" src="https://www.ref-fr.pm.dev/res/co/0/www/www/59901/ea.js"></script>

<script type="text/javascript">
/*<![CDATA[*/
EA_collector([
'email', 'pauldavidwilliamms@btinternet.com.toto'
,'ref', '70608843'
,'amount', '34.43'

,'prdref', '104715338'
,'prdamount', '11.00'
,'prdquantity', '1'
,'prdref', '104715337'
,'prdamount', '2.56'
,'prdquantity', '1'
,'prdref', '104715339'
,'prdamount', '6.00'
,'prdquantity', '1'
,'prdref', '104715336'
,'prdamount', '0.90'
,'prdquantity', '1'
]);
/*]]>*/
</script>
<!-- /Eulerian Analytics - / scartamount -->
Commentaire de Carole Boucheny [ 31/mars/10 11:10 ]
Claire,

Peux-tu recetter stp ? Pour tester c'est le même principe que pour le jira : APP-28624.

Merci
Carole
Commentaire de Claire Genty [ 31/mars/10 11:40 ]
Carole,

Je viens de tester et voici ce que j'obtiens.

<!--@@@ Panier : Event - Buy -->
<!-- Eulerian Analytics - / scartamount -->
<script type="text/javascript" src="https://www.ref-fr.pm.dev/res/co/0/www/www/59901/ea.js"></script>

<script type="text/javascript">
/*<![CDATA[*/
EA_collector([
'email', 'fabrice.feugas+acheteurfab@gmail.com'
,'ref', '70608844'
,'amount', '3.80'

,'prdref', '104715340'
,'prdamount', '0.90'
,'prdquantity', '1'
]);
/*]]>*/
</script>
<!-- /Eulerian Analytics - / scartamount -->
<!--@@@ End of transaction tag : Event - Buy -->


Effectivement, les variables suivantes ne sont pas récupérées :
   ,'type', 'TYPE_DE_COMMANDE'
   ,'payment', 'TYPE_DE_PAIEMENT'
   ,'prdname', 'NOM_DU_PRODUIT_VENDU 1' /* optionnel */

Comment cela se fait-il?

Merci

Claire
Commentaire de Alexandre Garnier [ 01/avr./10 12:48 ]
Là je crois qu'il y a un gros mélange :
* ce qui a été intégré est nullement dynamique
* ce qui semble ressortir lors des recettes, ce sont les tags EULERIAN des "Emails abandonnistes" (/promotions/Promotions/FR/Affiliation/Emails abandonnistes/) !

Ce qui soulève un problème : comment vont fonctionner 2 tags EULERIAN identiques en parallèle ?
Commentaire de Carole Boucheny [ 01/avr./10 14:08 ]
Alexandre,
Est-ce qu'utiliser les flux BI comme tu proposais dans la sous-tâche règlerais le problème ? Par contre, je ne sais pas du tout comment ça fonctionne...

Claire,
Est-ce que de ton côté ça pourrait-être une solution envisageable ?

Merci
Carole
Commentaire de Alexandre Garnier [ 01/avr./10 14:31 ]
Attention, je partais juste dans un délire...
Commentaire de Carole Boucheny [ 06/avr./10 14:13 ]
Claire

Est-ce que ce tag doit se déclencher uniquement pour un premier achat ? Si oui, peux-tu tester ?

Merci
Commentaire de Claire Genty [ 06/avr./10 19:47 ]
Carole,

Peux-tu me communiquer sur quels événement étaient paramétrés les codes de tracking du tag précédent?

Si ces derniers sont paramétrés sur le premier achat, ce tag également. (il me semble que c'était le cas)

Merci par avance

Claire

PS : je teste demain dans la journée
Commentaire de Carole Boucheny [ 07/avr./10 08:50 ]
Bonjour Claire,

L'ancien tag se déclenchait que sur le premier achat.
Par contre, comme l'a noté Alexandre dans le jira en sous-tâche les informations "Type de commande", "type de paiement" et "nom du produit" ne peuvent pas être récupérées. C'est donc pour cela qu'elle ne remontent pas.
Commentaire de Claire Genty [ 07/avr./10 17:02 ]
Bonjour Carole,

Je viens de tester, ça m'a l'air ok.
Si l'ancien tag se déclenchait sur le 1er achat, il en est de même pour celui-ci.

Merci

Claire

voici ce que j'obtiens:
<!--@@@ Panier : Event - Buy -->
<!-- Eulerian Analytics - / scartamount -->
<script type="text/javascript" src="https://www.ref-fr.pm.dev/res/co/0/www/www/59901/ea.js"></script>
<script type="text/javascript">
/*<![CDATA[*/
EA_collector([
'email', 'fabrice.feugas+acheteurfab@gmail.com'
,'ref', '70656044'
,'amount', '3.80'

,'prdref', '104760535'
,'prdamount', '0.90'
,'prdquantity', '1'
]);
/*]]>*/
</script>
<!-- /Eulerian Analytics - / scartamount -->
<!--@@@ End of transaction tag : Event - Buy -->
Commentaire de Carole Boucheny [ 07/avr./10 17:07 ]
Claire,

Il existe un autre tag Eulerian actuellement, c'est celui-ci que tu as eu. Le tag que j'ai mis en place commence par :
<!-- Eulerian Analytics - priceminister-fr / scartamount --> et ne récupère pas l'email.

Peux-tu retester avec spot_back : http://bo.ref-fr.pm.dev/spot_back
Il faut cocher "traking" et mettre le niveau à "High". Pour l'url, il faut mettre /info/home?t=2294340

Merci
Carole
Commentaire de Claire Genty [ 07/avr./10 17:36 ]
Tag Quamedia sous spot
Commentaire de Claire Genty [ 07/avr./10 17:36 ]
Carole,

Merci pour cette précision.

J'ai retesté via spot avec le code 2294347.

Voici donc ce que j'obtiens en pj (je vais y arriver... :-))
Si je comprend bien, nous ne remontons que le nombre de produits achetés?

Merci

Claire

En pj ce que je vois.
Je ne trouve pas de tag commençant par <!-- Eulerian Analytics - priceminister-fr / scartamount -->.
Je trouve juste : <!-- Eulerian Analytics - / scartamount -->
Commentaire de Claire Genty [ 08/avr./10 09:51 ]
Carole,

Comme vu avec toi, nous récupérons le bon tag.
L'acheteur que j'avais pris avait déjà acheté sur le site.
Je ne pouvais donc pas voir le tag 1er achat :-)

Merci

Claire
Commentaire de Carole Boucheny [ 08/avr./10 10:04 ]
(Promo) Soumis à publication sur cms ref
Commentaire de Carole Boucheny [ 09/avr./10 11:55 ]
Publié sur cms ref




[BIN-644] [Marketing] : Validation et disposition dans un dossier public du rapport "Affiliation sur commission nette hors FP par groupe de tracking du panier et filtre sur 30jrs !!!" Création: 07/janv./10 15:52  Mise à jour: 25/janv./10 16:34  Résolue: 25/janv./10 10:50

Etat: Fermé
Projet: Business Intelligence
Composants: Partners
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Jonathan Gorges Attribution: Cyril Tanneau
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Avec Dalila, nous avons corrigé un rapport appelé "Affiliation sur commission nette hors FP par groupe de tracking du panier et filtre sur 30jrs !!!", disponible aujour'hui sur Mes Dossiers -> Favoris -> Jonathan.

Nous voulons valider et disposer 2 rapports de ce type dans le dossier public Affiliation.

La correction qui a été effectuée et qui est cruciale est le Filtre "Last Tracking 30 jours" qui n'était pas présent sur ce rapport. Ainsi, les paniers que nous remontons via ce rapport doivent absolument être Last Tracking 30 jours.

Voici les rapports devant être créés:
- "Affiliation sur commission nette hors FP par groupe de tracking et par datte": il s'agit exactement de celui disponible dans le dossier Jonathan, avec le filtre Last Tracking 30 jours, et permettant de choisir une date de sélection de ce type [aaaa/mm/jj]

- "Affiliation sur commission nette hors FP par groupe de tracking mois coulant": il s'agit du même rapport, avec le filtre Last Tracking 30 jours, mais avec un filtre "mois coulant" à la place de la sélection des dates.
   -> Nous voulons planifier l'export de ce reporting tous les Lundi à midi pour les groupes de tracking suivant : Affiliationx, Cibleclicx, Zanoxx.
   -> From : Validation des Ventes [[Groupe de Tracking]]
   -> Destinataire : affiliation2@priceminister.com

PS : afin d'éviter toute confusion, les 3 groupes de Tracking possèdent un "x" à la fin.

Une fois de plus, le plus important est de s'assurer que les paniers sont bien Last Tracking 30 jours.

Je reste à votre disposition pour toute information complémentaire.

Merci d'avance pour votre retour.

JG

 Commentaires   
Commentaire de Cyril Tanneau [ 08/janv./10 16:23 ]
Jonathan,

comme vu ensemble, voici les modifications à apporter sur les rapports BO contenus dans le dossier Public/Pays/Affiliation:

Affiliation sur commission nette hors FP par groupe de tracking du panier
     --> Ajout du tracking 30 jours et déclinaison du rapport sous 2 formes:
     --> PriceMinister - Affiliation sur commission nette hors FP par groupe de tracking du panier (avec sélection de dates d'autorisation)
     --> Partner- Affiliation sur commission nette hors FP par groupe de tracking du panier (30 derniers jours autorisation, rapport à planifier)

Affiliation sur volume d'affaires par groupe de tracking du panier
     --> Rapport non utilisé, à archiver

Partner - Affiliation purchase checking
     --> Rapport non utilisé, à archiver

PriceMinister - Affiliation purchase checking
     --> Ajout du tracking 30 jours

On ne touche pas aux rapports de type "Seller..." du dossier Affiliation.

Peux-tu valider ces modifications et je commence les développements.

Merci,

Cyril
Commentaire de Jonathan Gorges [ 08/janv./10 16:52 ]
Hello,

Tout cela est parfait!

Merci bcp.

JG
Commentaire de Jonathan Gorges [ 18/janv./10 12:35 ]
Hello Cyril,

Comment vas-tu?

Je reviens vers toi concernant les rapports Affiliation sur commission nette hors FP par groupe de tracking du panier.

As-tu déjà rajouté le filtre Last Tracking 30 jours ? J'ai essayé d'utiliser ce rapport ce matin mais il me semble que le filtre n'a pas encore été posé.

Merci d'avance pour ton retour.

JG
Commentaire de Dalila Belkebir [ 18/janv./10 14:33 ]
Bonjour Jonathan,

Je dois avlider les rapports. Je le fais demain matin et te les livre en prod dans la foulée si tout est ok.

Cdlt,
Dalila.
Commentaire de Jonathan Gorges [ 18/janv./10 14:38 ]
"avlider" ? Vous utilisez de drôles de termes chez BI :-)

Blague à part, pas de problème.

Merci encore.

JG
Commentaire de Cyril Tanneau [ 21/janv./10 18:01 ]
Bonjour,

Conformment à la demande, les rapports suivants sont passés en prod:
     --> PriceMinister - Affiliation sur commission nette hors FP par groupe de tracking du panier (avec sélection de dates d'autorisation)
     --> Partner- Affiliation sur commission nette hors FP par groupe de tracking du panier (30 derniers jours autorisation, rapport à planifier)
     --> PriceMinister - Affiliation purchase checking

Ces trois rapports sont désormais filtrés en "Last tracking 30 jours".

Recapitulatif: Vous trouverez donc dans le répertoire affiliation les rapports suivants:

France
     --> PriceMinister - Affiliation sur commission nette hors FP par groupe de tracking du panier
     --> Partner- Affiliation sur commission nette hors FP par groupe de tracking du panier
     --> PriceMinister - Affiliation purchase checking

Espagne
     --> PriceMinister - Affiliation purchase checking

UK
     --> PriceMinister - Affiliation purchase checking

Jonathan, Benjamin, pouvez-vous valider la demande si cela vous convient?

Nous restons à votre disposition pour toute question.

merci,

Cyril
Commentaire de Jonathan Gorges [ 22/janv./10 09:12 ]
Hello,

Tout cela me convient parfaitement.

Merci pour tout et bonne journée.

JG
Commentaire de Benjamin Guerville [ 25/janv./10 16:34 ]
ok pour moi
merci




implémentation stats auto (APP-6505)

[APP-6506] collecte des stats auto sur un répertoire partagé Création: 28/nov./05 16:43  Mise à jour: 25/juin/07 18:33  Résolue: 03/févr./06 10:32

Etat: Fermé
Projet: Application PriceMinister
Composants: Annonces
Affecte la/les version(s): 8.0.9
Version(s) corrigée(s): 8.1.1

Type: Sous-tâche Priorité: Majeur
Rapporteur: Marc Cacheiro Attribution: Edouard Laurent
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Duplicate
doublon de EXP-671 Mettre a jour le fichier log4j.xml Résolu
Site: Prod

 Description   
(dépendance tâche dev "implémentation stats auto", JIRA n°6505)

- à partir des fichiers CSV générés par l'équipe dev via les logs 4J sur chacun des 11 sevreurs applicatifs, création d'une table unique à destination de l'équipe décisionnelle, comprenant pour chaque log enregistré sur les serveurs les colonnes suivantes :

. type de page (détail annonce ou liste annonce)
. type de vendeur (part ou pro)
. id_vendeur
. marque
. modèle
. version
. id_annonce
. date de consultation

- mise à disposition de cette table sur un répertoire partagé à destination de l'équipe décisionnelle

 Commentaires   
Commentaire de Sébastien Tournay [ 28/nov./05 18:00 ]
PAs certain que cela soit du ressort de l'exploit. Une tache pour le décisio ? Je te laisse voir.
Commentaire de Christophe Garcia [ 14/déc./05 10:56 ]
Où en est-on SVP ?
Commentaire de Christophe Garcia [ 15/déc./05 10:35 ]
Judd,
Merci de fournir à Edouard les infos nécessaires à la recup et archivage des fichiers.
Commentaire de Judd OSullivan [ 15/déc./05 11:23 ]
Sur chaque machine il y a ce fichiers :
/appli/priceminister/jboss/server/priceminister/log/reporting/stats_auto.csv

Chaque matin au démarrage il y aura 2 fichiers :
stats_auto.csv : les stats depuis minuit
stats_auto.csv.2005-12-14 : les stats avant minuit

Ensuite il me semble que les deux sont ecrasés parce qu'on supprime le rép ..../priceminister/log. Si on veut integrer leur récuperation dans le processus de démarrage on peut changer log4j pour que tout soit dans un seul fichier. Au moins il faut qu'on copie ces 2 fichiers ailleurs au démarrage.
Commentaire de Edouard Laurent [ 15/déc./05 16:09 ]
les stats auto sont dispos sur titan dans /data/priceminister/pmshare/exploit/log4j/work/stats_auto.csv
pour l'instant le mecanisme n'est pas automatise

Commentaire de Agathe Remy [ 15/déc./05 18:15 ]
En fait, il faudrait chargé les données du fichier .csv dans une table du Datawarehouse sur Titan (mais qui ne soit pas détruite pendant la synchro) pour que je puisse faire mes requêtes.

Merci:-)
Commentaire de Edouard Laurent [ 16/déc./05 12:27 ]
J'ai fait une demande auprès de Didier Blanc, nous avons déjà ce type de schéma (non supprime) sur titan pour l'archivage
en attente de sa réponse.
Commentaire de Edouard Laurent [ 16/déc./05 17:31 ]
en regardant un peu le fichier je tombe sur pas mal de lignes comme celle la,
particulierement sur venus
stats_auto.csv:liste_annonces;part;2618751;null;null;null;null;2005-12-16 15:58:46.277

Bug ? ca parait etrange, ca resemble a une ligne de log qui sert a rien
Commentaire de Edouard Laurent [ 04/janv./06 17:03 ]
Collecte des stats auto :
================
en tant que pmas@titan dans le repertoire : /data/priceminister/pmshare/exploit/stats_auto
executer le script: ./stats_auto.sh collect

une fois la collecte des logs effectue. les fichiers log archives et traites par le mecanisme de collecte sont stockes dans
/data/priceminister/pmshare/exploit/stats_auto/archive/

Les enregistrements selectionnes valide par le pre-traitement sont stockes dans le fichier :
/data/priceminister/pmshare/exploit/stats_auto/work/date_du_jour-current.csv

Les enregistrements rejettes par le pre-traitement sont stockes dans le fichier :
/data/priceminister/pmshare/exploit/stats_auto/work/date_du_jour-null.csv

Chargement des stats auto dans ORACLE :
===========================
pour charger les stats dans la table "consultation_history" du schema "log4j/log4j@GLOB.TITAN"

en tant que pmas@titan dans le repertoire : /data/priceminister/pmshare/exploit/stats_auto
executer le script: ./stats_auto.sh load

les logs du chargement sqlldr sont disponible dans :
/data/priceminister/pmshare/exploit/stats_auto/work/log


Remarques :
========
* L'ensemble de la chaine a ete teste et fonctionne correctement. cependant il y a beaucoup de doublon dans la table "consultation_history" car les fichiers de log ont ete stockes en double (Ranto a corrige le pb et il est entrain de faire le menage ). Il faut donc re-proceder a un cycle complet pour avoir des donnees coherantes dans "consultation_history" ce qui sera fait le 5 Jan 06

* Il est possible que creer un dblink entre la base OLTP (jupiter) et BW (titan) pour pouvoir consulter la table "consultation_history" depuis l'OLTP



Commentaire de Christophe Garcia [ 11/janv./06 17:09 ]
Où en sommes-nous ?
Le process de collecte des fichiers et d'import dans la base BI est-il en place ?
Commentaire de Edouard Laurent [ 12/janv./06 11:28 ]
Tout fonctionne, ce n'est pas automatise, je fais le chargement a la main actuellement

Les donnees "VALIDES" sont disponibles dans consultation_history du schema log4j/log4j@GLOB.TITAN

Commentaire de Arnaud Forgues [ 13/janv./06 15:19 ]
Trois points d'améliorations pour le chargement des données pour la V810 :

1/ Afin d'optimiser les calculs de vues matérialisées sur cette table de données brutes (consultation_history), il faudrait ajouter lors du chargement de données (avec le SQL LOADER) une colonne à cette table contenant le premier jour de la semaine de chauqe date de consultation :
         --> c'est à dire : TRUNC(:consultation_date, 'D')

Pour les données déjà chargée il faudra :
- soit vider la table et recharger toutes les données avec cette nouvelle pseudo colonne
- soit passer les scripts suivants :
          CONNECT log4j/log4j@&INSTANCE
          ALTER TABLE consultation_history ADD week_start_date DATE;
          UPDATE consultation_history
          SET week_start_date = TRUNC(consultation_date, 'D');
          COMMIT;
          ALTER TABLE consultation_history MODIFY week_start_date NOT NULL;

2/ Afin d'éviter les problèmes de lignes erronées dues à la présence d'un ";" dans un des champs chargés, on va remplacer le séparateur par un "§" (le "paragraphe" situé sur la touche "!" avec un "Shift")

3/ Enfin d'afin d'éviter les doublons pour identifier un véhicule donné, il faudrait s'assurer que le Charset est correct sur tous les SA en PROD car on a pu constater l'erreur suivante sur un modèle BMW qui apparaissait des deux manières suivantes : "Série 5" et "S¿rie 5"

Merci !!!
Commentaire de Arnaud Forgues [ 16/janv./06 18:58 ]
La partie mise à jour des données déjà chargée du point 1/ a déjà été faite par Patrick et moi-meme lors du passage des scripts des pré-déploiement V810.

Il reste donc l'ajout de la nouvelle colonne dans le script du SQLLOADER et également les points 2/ et 3/
Commentaire de Edouard Laurent [ 17/janv./06 18:00 ]
voila le control_file utilise pour charger les donnees :

load data
infile '$WORK_DIR/$TODAY-current.csv'
append
into table consultation_history
fields terminated by "§"
trailing nullcols
(
page_type,
seller_type,
seller_account_id,
manufacturer,
model,
version,
cpl_product_id,
consultation_date timestamp 'YYYY-MM-DD HH24:MI:SS.FF3',
manufacturer_key,
model_key,
version_key,
has_photo,
has_warranty,
brand_id INTEGER EXTERNAL TERMINATED BY "\r",
week_start_date "TRUNC(TO_TIMESTAMP(:consultation_date,'YYYY-MM-DD HH24:MI:SS.FF3'), 'D')"
Commentaire de Patrick Pereira [ 19/janv./06 19:12 ]
REFRESH DES VM:
----------------------------


A la fin du load des données, en tant que log4j passer la commande :

exec REFRESH_STATS_OLTP_VM;

et voilà.

Cette procédure met à jours les vm sur titan et sur jupiter.
Commentaire de Christophe Garcia [ 20/janv./06 12:15 ]
Edouard,
Le JIRA APP-7092 saisi par Manuel précise qu'il faut supprimer certaines colonnes de ton SQL Loader.
Est-ce que c'est pris en compte ?
Commentaire de Edouard Laurent [ 25/janv./06 09:56 ]
Nous avons fait la modification suite au mini-deploiment. Les 3 colonnes on etait place en status UNUSED dans la table consultatation_history.
Il faudrat proceder a un suppression definitive des ces colonnes dans le futur.

J'ai tester integralement la chaine stat auto ce matin :
"pmas@titan" : dans le rep "/data/priceminister/pmshare/exploit/stats_auto"

./stats_auto.sh collect : recupere et concataine les logs auto des serveurs JBOSS : ras, plus aucune ligne avec des NULL
./stats_auto.sh load : charge les donnees dans la table consultation_history : sur 2 984 075 lignes chargees, 6151lignes rejetees, en grande partie a cause de "version_key" non existant
./stats_auto.sh refresh : met a jour les VM : ras

Je pense que l'on peut automatiser le processus. Fait de maniere quotidienne il faut prevoir ~ 20 Min pour l'ensemble

OK pour le dev ?



Commentaire de Edouard Laurent [ 27/janv./06 09:59 ]
Pour Manu :
voici un extrait des lignes rejettees par le loader :
Pour info,
Hier :
====
Total logical records read: 542040
Total logical records rejected: 37283

Aujourd'hui :
========
Total logical records read: 560034
Total logical records rejected: 1123

Extrait des bad d'hier :
==============

liste_annonces§part§2610047§7377877§2006-01-25 15:16:10.803§PM04000443§PM07992714§§0§0§0
liste_annonces§part§4775233§7175950§2006-01-25 15:28:35.089§M126732§PM00490443§§1§0§0
liste_annonces§part§4687193§6968151§2006-01-25 15:28:35.09§M126732§PM07991362§§0§0§0
liste_annonces§part§4712576§7028811§2006-01-25 15:33:21.873§PM07991718§PM07991840§§0§0§0
liste_annonces§part§4712576§7028811§2006-01-25 15:34:16.438§PM07991718§PM07991840§§0§0§0
liste_annonces§part§2610047§7377877§2006-01-25 15:35:30.742§PM04000443§PM07992714§§0§0§0
liste_annonces§part§2610047§7377885§2006-01-25 15:36:03.301§PM04000443§PM07993204§§0§0§0
liste_annonces§part§2927512§6628676§2006-01-25 15:36:36.86§PM04000443§PM08120444§§0§0§0
liste_annonces§part§4755962§7135128§2006-01-25 15:44:22.79§PM07989541§PM08007902§§0§0§0
liste_annonces§part§4755962§7135128§2006-01-25 15:44:22.814§PM07989541§PM08007902§§0§0§0
liste_annonces§part§4755962§7135128§2006-01-25 15:44:24.454§PM07989541§PM08007902§§0§0§0
liste_annonces§part§4755962§7135128§2006-01-25 15:44:24.738§PM07989541§PM08007902§§0§0§0
liste_annonces§part§4755962§7135128§2006-01-25 15:45:05.005§PM07989541§PM08007902§§0§0§0
liste_annonces§part§4703030§6992921§2006-01-25 16:16:36.136§PM07876863§PM07987282§§0§0§0
liste_annonces§part§2610047§7377877§2006-01-25 16:37:17.819§PM04000443§PM07992714§§0§0§0
liste_annonces§part§4742657§7100876§2006-01-25 16:55:54.898§PM07944145§K07993§§0§0§0
liste_annonces§part§949043§7134255§2006-01-25 16:55:54.898§PM07944145§K07993§§1§0§0
liste_annonces§part§4755962§7135128§2006-01-25 17:00:40.155§PM07989541§PM08007902§§0§0§0
liste_annonces§part§4693903§7137723§2006-01-25 17:06:02.57§PM07714853§K02480§§0§0§0


Extrait des bad d'aujourd'hui :
===================

liste_annonces§pro§9402304§16992429§2006-01-26 14:58:02.526§M126732§PM07991365§§1§0§0
liste_annonces§pro§4489714§9051027§2006-01-26 14:59:13.94§PM07989642§PM07989801§§0§0§0
liste_annonces§pro§9402304§16992429§2006-01-26 14:59:41.654§M126732§PM07991365§§1§0§0
liste_annonces§pro§4489714§9051027§2006-01-26 15:01:32.48§PM07989642§PM07989801§§0§0§0
liste_annonces§part§4731898§7048225§2006-01-26 16:11:42.875§PM07993538§PM08072367§§0§0§0
liste_annonces§part§4733877§7121663§2006-01-26 16:11:42.891§PM07993356§K04180§§0§0§0
liste_annonces§part§4756570§7136451§2006-01-26 17:23:02.027§PM04000443§M110394§§0§0§0
liste_annonces§part§4693903§7137723§2006-01-26 17:25:01.78§PM07714853§K02480§§0§0§0
Commentaire de Christophe Garcia [ 31/janv./06 16:10 ]
Edouard,
Je vais ouvrir un autre JIRA pour le pb que tu signales ci-dessus.
Merci de fermer ce JIRA si la tâche "collecte de stats auto" est complètement implémentée de ton côté.
Commentaire de Sébastien Tournay [ 31/janv./06 17:37 ]
Edouard,

On vient de recharger ce matin les données du au fait que le DW n'était pas synchronisé au moment du lancement du CRON. Il faut prévoir ce cas de figure pour relancer automatiquement (au même titre que ce que nous faisons avec EMV, partnership..).

On constate également toujours de plusieurs lignes dans le fichier bad. Je voudai bien comprendre à quoi cela correspond. ESt-ce normal ? Devons-nous nous en inquiéter ?
Commentaire de Arnaud Forgues [ 31/janv./06 17:51 ]
Il peut s'agir soit :
- des lignes de logs archivées a moitié lors du redémarrage des serveurs (donc autant qu'il y a de SA)
- des lignes de logs des véhicules qui n'ont pas d'attribut "En-tete / Version" (voir le JIRA APP-7232) ==> vous n'avez donc pas a vous en inquieter
- autre ???

Arnaud
Commentaire de Christophe Garcia [ 13/févr./06 19:09 ]
OK pour la collec des stats en automatique




[DEC-201] création d'un rapport permettant de suivre l'évolution du nombre de parrain Création: 15/déc./05 18:25  Mise à jour: 14/sept./07 14:18  Résolue: 23/oct./06 12:33

Etat: Fermé
Projet: Reporting
Composants: Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Thomas Beylot Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 4 heures
Temps consacré: Non spécifié
Estimation originale: 4 heures


 Description   
Bonjour,

Comme nous allons améliorer le système de parrainage, il me faudrait plus d'indicateurs pour établir sa cohérence et ses performances.

En fait, il me manque une donnée essentielle qui est le nombre de parrains PriceMinister.

Serait-il possible de créer ce rapport?

merci,

thomas.


 Commentaires   
Commentaire de François Le Lay [ 04/janv./06 13:09 ]
Tu souhaites que ce rapport soit hebdo, quotidien ou mensuel?
Pour info au jour d'aujourd'jui, on 39328 parrains et 115363 filleuls, tous types de comptes confondus (inclus donc les comptes de type contact qui n'ont pas été transformés en compte normal suite à un achat.)

Commentaire de François Le Lay [ 04/janv./06 17:50 ]
Thomas je mets cette demande en standby jusqu'à ce que tu me dises précisement les indices dont tu as besoin (type de compte filleul contact ou normal, dormants ou non, pourcentage et/ou nombre, cumul et/ou nouveaux filleuls/parrains par jour/mois/année ....)
Commentaire de Thomas Beylot [ 19/sept./06 11:48 ]
yo

je faisais un pti tour des jira et me suis rendu compte que celui-ci trouvait sa réponse dans un autre (BIN-153) mais je crois que c'est encore Agathe qui le tient.

Soit dit en passant ça serait cool si on pouvait le traiter car le parrainage sort avec la prochaine version. Aussi si je pouvais avoir les indicateurs pour voir si les projets qu'on met en place sont efficaces ce serait quand même pas mal :-)

voilou,

thomas.
Commentaire de Agathe Remy [ 19/sept./06 13:59 ]
Hello,

En effet, je met ce JIRA en doublon de l'autre.
Pour ton information, j'ai plannifier ce projet pour fin 2006.
Il sera traité après le projet 1000Mercis lot 1 et le BI Espagne, à savoir en décembre.

Cordialement,
Agathe




[BIN-679] [Partners] : Kelkoo Vente : modification modèle de rémunération appel à facture Création: 18/juin/10 16:43  Mise à jour: 13/sept./10 10:05  Résolue: 01/juil./10 10:08

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Claire Genty Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   

Bonjour Agathe,

Nous sommes entrain de changer de modèle de rémunération pour Kelkoo vente (module spécifique en bas de page du comparateur).

Actuellement 2 appels à factures :

Ces 2 appels ont pour modèle de rémunération (6¿ membre actif + 5% VA) :
¿ Kelkoo - Appel à facture hebdomadaire
¿ Kelkoo - Appel à facture mensuel

Le nouveau modèle sera donc le suivant 0,03¿/ visite source Xiti + 7¿/membre actif à partir du 1er juillet 2010.

Pourras-tu modifier les 2 rapports à partir du 10/07? (après envoi de l'appel à facture de juin sur ancien modèle avec VA le 9/07)

Merci par avance

Claire



 Commentaires   
Commentaire de Agathe Remy [ 21/juin/10 17:50 ]
Bonjour Claire,

L'ancien modèle de rémunération du rapport était :
- 5% du VA capturé TTC frais de port inclus, hors CBV et jors EG
- 6 euros par membres actifs

Les visites Xiti n'étant pas importées dans BI, nous ne pouvons pas calculer les revenus associés.
Le nouvel appel à facture ne doit-il plus se baser que sur le nombre de membres actifs? Plus du tout sur le VA?

Merci,
Agathe
Commentaire de Benoit Tabaka [ 22/juin/10 09:09 ]
De mon côté, la revue du nouveau OI a été réalisé hier.

On a effectivement, comme l'indique Claire, un nouveau modèle économique :
- un CPC (dont les données sont donc entre les mains de Kelkoo)
- un CPA pour tout nouveau membre actif (membre faisant une première mise en vente ou membre faisant un premier achat).

Question plus pour Claire : dès lors que l'on donne accès à Xiti à Kelkoo (qui donc a priori peut récupérer les données "nouveau membre"), est-il encore nécessaire que du côté de PM nous fassions un appel à facture ?

Avec le précédent modèle éco basé sur un Rev Share, c'était nécessaire. Mais là, ce sont des données que Kelkoo est susceptible de récupérer comme un grand (via ses systèmes pour le CPC ou via Xiti pour le CPA).
Commentaire de Claire Genty [ 22/juin/10 11:51 ]
Agathe, Benoit,

Effectivement, pas besoin d'appel à facture pour Kelkoo Vente étant donné que tout est basé sur des datas Xiti. Mea culpa :-)
Kelkoo va donc récupérer les données via son accès Xiti personnalisé et de mon côté je ferai de même chaque début de mois.

Le nouveau modèle de rémunération prend effet le 1/07/2010.
Ainsi, l'appel à facture actuel prend fin le 10/07/2010 (dernier appel à facture pour juin).

Merci encore

Claire
Commentaire de Agathe Remy [ 13/sept./10 10:05 ]
Les appels à facture ont bien été désactivés.

Agathe




[BIN-123] [Parrainage] : Demande de nouveaux rapports Création: 12/juil./06 18:32  Mise à jour: 14/sept./07 17:17  Résolue: 26/avr./07 20:05

Etat: Fermé
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Thomas Beylot Attribution: Agathe Remy
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word Brief rapport parrainage.doc    
Liens des demandes:
Dépendance
bloque BIN-272 [Parrainage] : Nouveaux rapports Fermé

 Description   
hello

le projet parrainage est ressorti du fin fond de nulle part, avec une mise en prod prévue pour fin du mois d'août.

Aussi je ressors le document en pj, qui récapitule les datas dont j'aurais besoin afin de suivre l'impact des actions qui vont être implémentées.


A votre dispo pour en parler et prioriser le cas échéant.

merci,

thomas.

 Commentaires   
Commentaire de Thomas Beylot [ 12/juil./06 18:33 ]
voilà le doc, en pj.
Commentaire de Agathe Remy [ 26/sept./06 12:16 ]
Voir ce qui est disponible dans Customer Followup avec MEZ.
Commentaire de Agathe Remy [ 12/déc./06 17:25 ]
Un petit rapport sur les points en suspens sur le rapport de parrainage de Thomas.

Le nombre de filleuls total est égal au nombre de filleuls inscrits. Il n'y a pas de filleuls en type contact !
Le nombre de parrains dormants est erroné. Je l'ai donc supprimé du tableau.
La requête parait complexe sur BO puisqu'il faut compter le nombre de parrain qui ont déjà des filleuls actifs mais qui n'ont pas parrainé au mois M et qui n'ont pas de filleuls devenus actifs au mois M.

Pourtant on a essayé avec Thomas de le résoudre mais mon cerveau devait être en mode : Parrain dormant.
Commentaire de Agathe Remy [ 12/déc./06 18:04 ]
Avec Quentin, nous avons vu que les informations de parrain ne sont pas enregistrées au niveau du compte utilisateur tant que celui-ci ne s'est pas inscrit au site.
Le seul moyen de suivre les parrains potentiels (i.e. n'ayant pas de filleul inscrit) et les filleuls non inscrits est donc de suivre les mails de parrainage envoyé par le site (table FRIEND_MAIL).
Or ces informations ne sont pas aujourd'hui disponibles dans BI. Il s'agit d'un vrai projet technique pour insérer ces infos.

Thomas, pourrais-tu commenter ce JIRA avec le nom du rapport développé par MEZ et la liste des informations aujourd'hui disponibles dans ce rapport, ainsi que celle des informations manquantes?

Merci:-)

Agathe
Commentaire de Agathe Remy [ 19/janv./07 17:49 ]
Thomas,
Je me permets de te relancer afin que tu complètes ce JIRA : nous pourrons ensuite aborder ta nouvelle demande...

Merci:-)
Agathe




[DEC-403] Demande de rapport de meilleures ventes par catégorie Création: 26/juil./06 14:44  Mise à jour: 14/sept./07 14:44  Résolue: 02/nov./06 12:12

Etat: Fermé
Projet: Reporting
Composants: Trading
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Emmanuelle Lachamp Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
Hello !

Je voudrais connaitre les meilleures ventes (depuis le debut) pour les categories suivantes
puis par type de produits
Puericulture
vetement femme
vetement homme
vetement enfant
chaussures
materiel de sport
cosmetiques

merci

emma

 Commentaires   
Commentaire de Agathe Remy [ 02/nov./06 12:12 ]
D'après Pascal, le reporting demandé a été mis en place via 4D en septembre.
D'autre part, afin d'éviter de faire le même travail dans 4D et BI, toutes les demandes de reporting doivent être validées au préalable par Pascal.

Merci:-)

Cordialement,
Agathe




[APP-6526] gros pb sur la base : 100% de cpu, plein de lock sur une requete bien precise Création: 28/nov./05 18:50  Mise à jour: 25/juin/07 18:33  Résolue: 30/nov./05 15:35

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 8.0.8e

Type: Bogue Priorité: Majeur
Rapporteur: Justin Ziegler Attribution: Olivier Bernard
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File utilisateurs pas contents.msg    
Site: Prod

 Description   
PID=17177 BABEL_1 178,53203 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=13738 BABEL_1 149,41118 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=16506 BABEL_1 101,466 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17845 BABEL_1 192,63649 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=25813 BABEL_1 164,50845 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=14238 BABEL_1 100,63455 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17076 BABEL_1 47,7141 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=9997 BABEL_1 159,28863 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=16772 BABEL_1 151,2176 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=24733 BABEL_1 110,14413 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17485 BABEL_1 55,47501 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=14236 BABEL_1 50,35595 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=22146 BABEL_1 189,44120 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=23716 BABEL_1 99,35754 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=16500 BABEL_1 23,6491 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=20144 BABEL_1 83,46235 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17103 BABEL_1 128,53447 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17324 BABEL_1 38,61365 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=29852 BABEL_1 67,45110 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=26903 BABEL_1 107,19358 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=15615 BABEL_1 84,47373 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=23423 BABEL_1 105,22393 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=3844 BABEL_1 43,25069 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=8189 BABEL_1 141,42510 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17360 BABEL_1 165,6371 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=24696 BABEL_1 77,23254 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=20198 BABEL_1 94,61306 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=10049 BABEL_1 48,29287 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17222 BABEL_1 193,39519 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=28761 BABEL_1 37,55935 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=9080 BABEL_1 103,30903 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=16850 BABEL_1 202,2248 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=4930 BABEL_1 68,36171 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=8783 BABEL_1 174,44537 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=11898 BABEL_1 172,53020 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=28384 BABEL_1 70,31866 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=23388 BABEL_1 45,57739 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=2562 BABEL_1 56,20278 5 149 2157321 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304





PID=18442 BABEL_1 183,54034 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=22146 BABEL_1 189,44120 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17845 BABEL_1 192,63649 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17241 BABEL_1 71,21778 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=23231 BABEL_1 133,41904 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=5782 BABEL_1 145,59403 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=16772 BABEL_1 151,2176 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=18320 BABEL_1 109,28425 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17485 BABEL_1 55,47501 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=18309 BABEL_1 173,5228 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=14238 BABEL_1 100,63455 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=25813 BABEL_1 164,50845 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=16506 BABEL_1 101,466 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=26702 BABEL_1 32,47727 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=15615 BABEL_1 84,47373 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=11263 BABEL_1 136,454 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=23423 BABEL_1 105,22393 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=12089 BABEL_1 27,4195 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=16850 BABEL_1 202,2248 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17188 BABEL_1 121,62816 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=30981 BABEL_1 144,51033 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=16731 BABEL_1 122,41911 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=5193 BABEL_1 169,16297 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=6506 BABEL_1 66,24550 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17773 BABEL_1 160,29135 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=29852 BABEL_1 67,45110 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=26903 BABEL_1 107,19358 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=2059 BABEL_1 25,47793 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=8613 BABEL_1 139,42022 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17076 BABEL_1 47,7141 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=9997 BABEL_1 159,28863 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=16367 BABEL_1 200,638 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=25272 BABEL_1 102,55080 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=24696 BABEL_1 77,23254 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=20142 BABEL_1 117,17580 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=20198 BABEL_1 94,61306 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=10049 BABEL_1 48,29287 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=20146 BABEL_1 157,50460 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=28761 BABEL_1 37,55935 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=23578 BABEL_1 171,14149 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=9080 BABEL_1 103,30903 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=9994 BABEL_1 80,33162 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=18294 BABEL_1 81,61824 5 151 2157669 x SELECT prd_attribute_value_key, value, pattern FRO





[pmas@hercule priceminister]$ ./pmscripts/pmdatabase/utils/dba/report-expensive-session.sh glob | grep PID
PID=17179 BABEL_1 57,29784 -59154 1271 30311 x /* AttributeValueDependanceQuery */ SELECT /* 2214375796 89B81844
PID=23231 BABEL_1 133,41904 -59154 1271 30311 x /* AttributeValueDependanceQuery */ SELECT /* 2214375796 89B81844
PID=28761 BABEL_1 37,55935 -59154 1271 30311 x /* AttributeValueDependanceQuery */ SELECT /* 2214375796 89B81844
PID=30447 16,1 0 0 15665 x SELECT REOPEN_SECS FROM v$archive_dest WHERE dest_ 2144221516 8C833270
PID=21568 BABEL_1 24,64579 3 0 470539630 x SELECT DOCID FROM "PRODUCT_1"."DR$PRODUCT_IMX$K" W 1638776572 84F2F4F0
PID=30422 1,1 3 1 37555 x select o.owner#,o.name,o.namespace,o.remoteowner,o 431456802 79FF1DC4
PID=30438 9,1 3 1 37555 x select o.owner#,o.name,o.namespace,o.remoteowner,o 431456802 79FF1DC4
PID=18442 BABEL_1 183,54034 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=19607 BABEL_1 81,61859 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=16750 BABEL_1 182,25365 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=19965 BABEL_1 58,3562 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=8787 BABEL_1 177,9524 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=29852 BABEL_1 67,45110 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=21560 BABEL_1 14,31581 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17082 BABEL_1 118,31900 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=3844 BABEL_1 43,25069 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=25198 BABEL_1 44,37159 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=20008 BABEL_1 62,3765 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17188 BABEL_1 121,62816 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=19796 BABEL_1 130,25651 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=23578 BABEL_1 171,14149 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=9080 BABEL_1 103,30903 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=20135 BABEL_1 149,42752 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17103 BABEL_1 128,53447 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=18593 BABEL_1 39,18982 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=19771 BABEL_1 45,59262 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=23720 BABEL_1 28,44327 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=17076 BABEL_1 47,7141 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=20101 BABEL_1 78,17839 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=18511 BABEL_1 64,64551 5 156 2158748 x SELECT prd_attribute_value_key, value, pattern FRO 1630962956 84BBF304
PID=26903 BABEL_1 107,19358 6 21 6348975 x SELECT purchase_id, creation_date, change_date, pc 1065709384 87C5AB7C
PID=30436 8,1 12 0 15099 x select con#,type#,condlength,intcols,robj#,rcon#,m 1937775682 79FCFC1C
PID=20643 BABEL_1 191,23815 64 24 931621 x UPDATE PRODUCT SET IS_AVAILABLE = SIGN(:B14 + :B13 2980372004 82FFD1C0
PID=20361 BABEL_1 134,1017 71 8 19797093 x /* AttributeExtendedInfoQuery */ SELECT prd_a 1368569202 87506C9C
PID=20146 BABEL_1 157,50460 71 8 19797093 x /* AttributeExtendedInfoQuery */ SELECT prd_a 1368569202 87506C9C
PID=17392 BABEL_1 76,815 103 61 908500 x UPDATE ADVERT SET PRD_BEST_PRICE = :B8 , PRD_ADV_C 2094161026 82FFCD04
PID=8785 BABEL_1 120,10154 3950 3045 3 x /* ProductNavigationQuery::PowerCount */ SELECT 2817342393 8B745860
PID=24733 BABEL_1 110,14413 4471 3703 2 x /* ProductNavigationQuery::PowerCount */ SELECT 2355610782 8F95B408
PID=20415 BABEL_1 13,42036 4582 1086 427 x /* ProductNavigationQuery::PowerCount */ SELECT 3111732486 8248B0C8
PID=5782 BABEL_1 145,59403 4907 215 39459 x /* ProductNavigationQuery::Search */ SELECT / 1461890885 8B34EE34
PID=16367 BABEL_1 200,638 5376 365 40903 x /* ProductNavigationQuery::Search */ SELECT / 1123785949 930E5B28
PID=22146 BABEL_1 189,44120 5951 1824 964 x /* ProductNavigationQuery::PowerCount */ SELECT 3823848925 8AB2DD98
PID=20033 BABEL_1 179,24965 6461 3943 82 x /* ProductNavigationQuery::PowerCount */ SELECT 1179260981 96EF31AC
PID=20142 BABEL_1 117,17580 9108 46 645 x /* ProductNavigationQuery */ SELECT /*+ INDEX 1700859058 91767B5C
PID=18569 BABEL_1 42,53789 30491 1028 57943 x /* ProductNavigationQuery::Search */ SELECT /


Arret de tous les batch appli : le pb persiste.


La requete en question :

SELECT prd_attribute_value_key, value, pattern
FROM PRD_ATTRIBUTE_VALUE
WHERE prd_attribute_value_key=:1
FOR UPDATE



Pleins de lock bloquants sur la base.
Pleins de sessions actives pour tous les serveurs applis.



 Commentaires   
Commentaire de Justin Ziegler [ 28/nov./05 18:51 ]
Les paniers passent malgre tous !
Charge sur la base : 40

vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r b swpd free buff cache si so bi bo in cs us sy id wa
45 6 176 413792 155068 28228092 0 0 2 3 0 4 26 9 48 17
51 8 176 432480 155076 28221584 0 0 4148 1124 6956 4523 76 24 0 0
34 8 176 431904 155260 28226080 0 0 4792 652 8047 4474 77 23 0 0
38 8 176 439200 155456 28230304 0 0 5420 896 8640 5056 78 22 0 0
40 15 176 416608 155540 28234900 0 0 5100 1004 6734 3938 78 22 0 0
44 10 176 404832 155696 28240464 0 0 4672 3020 6413 3854 77 23 0 0
Commentaire de Justin Ziegler [ 28/nov./05 18:52 ]
iostat -x 1

avg-cpu: %user %nice %sys %iowait %idle
          73.91 0.00 26.09 0.00 0.00

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
cciss/c0d0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
cciss/c0d1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 14.85 50.50 14.85 847.52 237.62 423.76 118.81 16.61 0.42 6.64 5.06 33.07
sdb 0.00 16.83 154.46 16.83 2518.81 269.31 1259.41 134.65 16.28 1.23 7.90 3.84 65.84
sdc 0.00 8.91 49.50 8.91 752.48 142.57 376.24 71.29 15.32 0.41 8.02 5.10 29.80
sdd 0.00 15.84 80.20 15.84 1267.33 253.47 633.66 126.73 15.84 0.49 5.86 4.06 39.01
sde 0.00 21.78 65.35 23.76 1053.47 364.36 526.73 182.18 15.91 0.55 6.77 4.18 37.23
sdf 0.00 25.74 87.13 23.76 1504.95 396.04 752.48 198.02 17.14 0.73 6.76 4.41 48.91
sdg 0.00 7.92 84.16 7.92 1322.77 126.73 661.39 63.37 15.74 0.71 7.87 5.29 48.71
sdh 0.99 44.55 110.89 60.40 2067.33 831.68 1033.66 415.84 16.92 0.44 2.92 1.28 21.98
sdi 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdj 0.00 7.92 0.00 29.70 0.00 79.21 0.00 39.60 2.67 1.05 101.77 1.67 4.95
sdk 0.00 5.94 0.00 5.94 0.00 95.05 0.00 47.52 16.00 0.00 0.50 0.50 0.30

avg-cpu: %user %nice %sys %iowait %idle
          73.61 0.00 26.39 0.00 0.00

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
cciss/c0d0 0.00 1.00 0.00 2.00 0.00 24.00 0.00 12.00 12.00 0.00 0.50 0.50 0.10
cciss/c0d1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 32.00 37.00 32.00 704.00 512.00 352.00 256.00 17.62 0.27 3.96 3.19 22.00
sdb 0.00 38.00 144.00 38.00 3048.00 608.00 1524.00 304.00 20.09 0.79 4.31 3.23 58.70
sdc 0.00 29.00 69.00 29.00 1320.00 464.00 660.00 232.00 18.20 0.41 4.16 3.36 32.90
sdd 0.00 43.00 42.00 43.00 736.00 688.00 368.00 344.00 16.75 0.29 3.41 2.67 22.70
sde 0.00 37.00 56.00 35.00 848.00 576.00 424.00 288.00 15.65 0.35 3.86 3.22 29.30
sdf 0.00 37.00 64.00 37.00 1232.00 592.00 616.00 296.00 18.06 0.39 3.77 3.40 34.30
sdg 0.00 23.00 35.00 23.00 584.00 368.00 292.00 184.00 16.41 0.21 3.69 3.34 19.40
sdh 0.00 47.00 45.00 89.00 648.00 1088.00 324.00 544.00 12.96 0.25 1.87 0.87 11.70
sdi 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdj 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdk 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Commentaire de Justin Ziegler [ 28/nov./05 18:52 ]
donc : pas de saturation disque
Commentaire de Justin Ziegler [ 29/nov./05 16:29 ]
A plusieurs reprise, j'ai tue les sessions a problemes, mais de nouvelles arrivaient sans cesse.
Commentaire de Olivier Bernard [ 30/nov./05 12:18 ]
L'Ejb CMP AttributeValueBusiness est en mode de lock pessimiste comme la plupart des autres entités sur PriceMinister.
Dans ce cas précis, on ne modifie que très rarement ces éléments : par l'import CNET, ou manuellement par le BO.
On peut donc supprimer le lock pessimiste sur cet EJB Entité sans risque, afin d'enlever les locks for Update.
Commentaire de Olivier Bernard [ 30/nov./05 15:35 ]
Suppression du lock pessimiste via le fichier build.xml.
Commentaire de Laurent Merlet [ 08/déc./05 11:11 ]
Vu avec Olivier Bernard
testé en production




[DEC-22] Homogénéisation du calcul du volume d'affaires Création: 19/juil./05 15:18  Mise à jour: 10/sept./07 17:43  Résolue: 17/août/06 11:19

Etat: Fermé
Projet: Reporting
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Cosmétique
Rapporteur: François Le Lay Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
homogéniser le cacul du volume d'affaire pour les co-brandings, les trackings et les PurchaseByTracking.

 Commentaires   
Commentaire de François Le Lay [ 17/août/06 11:19 ]
inhérent au Lot Marketing BI




[APP-7057] IMPORT POLK: plusieurs valeurs en base pour le champ En-tête / Version Création: 16/janv./06 17:19  Mise à jour: 29/oct./09 10:12  Résolue: 26/oct./09 12:26

Etat: Fermé
Projet: Application PriceMinister
Composants: Base de données
Affecte la/les version(s): 8.1.0
Version(s) corrigée(s): 56.0.0 (TX-J)

Type: Amélioration Priorité: Majeur
Rapporteur: Patrick Condevaux Attribution: Emeric Teil
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à APP-7223 Eviter de créer plusieurs valeurs pou... Résolu
Site: Integ
Classif1: BP
Classif2: RBP - attribut
Projets PM archivés: AUTO : Nettoyage

 Description   
En consultant certain produit (par exemple Audi A6 2.5 TDi Pack Qtro. Avt BM6) on a 3 valeurs correspondant au champ En-tête / Version (apparement du a plusieurs import polk)

Cela pose un problème lors de la génération des statistiques des vendeurs auto APP-7052 qui se base sur cet valeur qui devrait etre unique.

Une unique valeur devrait exister pour ce champ.

 Commentaires   
Commentaire de Arnaud Forgues [ 16/janv./06 18:39 ]
On rencontre ce problème en INTEG. Est-ce le cas également en PROD ?

Je crois qu'un néttoyage avait été fait sur la base auto de PROD !?

D'autre part s'agit-il de problème avec les fichiers d'imports POLK ou du programme d'import lui-meme
Commentaire de Patrick Condevaux [ 17/janv./06 11:00 ]
Le probleme est le même en prod.

Voir par exemple les statistiques auto de LABELCARS

Ce probleme apparait sur environ 3800 annonces encore en vente ayant de 2 à 6 valeurs pour le champ entete/version
Commentaire de Marc Cacheiro [ 17/janv./06 17:59 ]
après discussion avec Quentin, il faut identifier la cause de la génération d'attributs multiples : imports POLK, imports pro, etc... (non seulement sur les versions mais sur tous les attributs), afin de chercher une solution qui pourra s'appliquer à tous les problèmes que cette anomalie peut soulever.
Commentaire de Arnaud Forgues [ 18/janv./06 15:12 ]
Après discussion avec Martin, le problème provient de la mauvaise gestion de collision dans l'import, dûe initialement a des données pourries dans les fichiers polk.

Pour règler ce problème il faudrait mettre en place cette notion de gestion de collision.

Cela est donc intrinsequement lié au chantier refonte de la base produit.

Je transmet donc le bug à Olivier.

NB1 : Pour plus d'infos sur les chiffres exacts d'attributs multiples sur fiches produits, on peut demander à Francois de l'equipe BI (qui a déjà réalisé un rapport la dessus)

NB2 : Jusqu'a présent, ce problème était connu mais n'avais pas d'impact génant sur l'application. Le cas présent des stats auto pourrait remonter la priorité de la refonte produit ...
Commentaire de Quentin de Chivré [ 18/janv./06 15:26 ]
Donc en fait il faut que je me leve , que j'aille voir Francois et que je lui demande son rapport si je veux plus d'informations ?

Je ne vois pas pourquoi tu transmet ca a Olivier (a Martin d'ailleurs) le pb reste critique sur les stats auto.
Commentaire de Arnaud Forgues [ 18/janv./06 16:18 ]
Concernant les chiffres de Francois, il a simplement 3 rapport sur les marques, modeles et versions multiples qui avaient été codé lors du choix de la base polk en juin dernier.
Pour être précis sur l'attribut "En-tete / Version", il y a 5500 annonces avec plus d'un attribut dont 2800 annonces actives (sur un total de 45 000 annonces actives !!).
J'ai demandé à Francois un rapport plus général pour tout attribut voiture : DEC-229

En ce qui concerne les stats auto, on va mettre en place une solution temporaire étant donné que la solution refonte base produit n'est pas immédiate.
Je laisse donc ce bug à Olivier pour la solution de fond et j'ouvre un autre bug à Manu pour les stats auto : APP-7098




Réinstallation de POMERY (EXP-784)

[EXP-786] Installation MINITOR sur POMERY Création: 05/janv./06 12:47  Mise à jour: 25/juin/07 18:55  Résolue: 31/janv./06 19:21

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: Sébastien Tournay Attribution: Xiaoming Du
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié


 Description   
dès la mise à disposition du nouveau POMERY (en principe semaine prochaine) par PAP, installer MINITOR sur ce serveur avec un profil BDD.

 Commentaires   
Commentaire de Xiaoming Du [ 18/janv./06 19:13 ]
un nouveau profile a été créé dans minitord pour BI. Pour le moment, il a les meme modules que profile BDD
Commentaire de Sébastien Tournay [ 19/janv./06 09:42 ]
Très bien. Il faut penser à mettre à jour le wuickview interne pour suivre son profil. Quels sont les alertes activées sur le profil de pomery ?
Commentaire de Xiaoming Du [ 31/janv./06 19:21 ]
http://bo.pm.lan/stats/mrtg/pommery/index.html

les supervisions de pommery est en place.Les alertes: diskuse, nocrond, nooraproc, dbconnect sont activées sur pommery.




[EXP-380] Eradication de la présence de /COVER Création: 21/nov./05 12:49  Mise à jour: 25/juin/07 18:54  Résolue: 15/févr./06 15:54

Etat: Résolu
Projet: Exploitation
Composants: Evolution
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Sébastien Tournay Attribution: Antoine Koener
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 10 minutes
Estimation originale: Non spécifié

Pièces jointes: Text File cover_15_dec_05.txt     Text File fichier_cover_trc_15_dec_05.txt    
Liens des demandes:
Duplicate
a pour doublon EXP-2486 Vérification de l'impact d'une suppre... Résolu

 Description   

Tu peux nous dire si on constate toujours des requêtes sur /cover dans les logs ? Sommes-nous certains que tout est migré sur /photo ? Cela vaut le coup de refaire une passe au niveau d'APACHE. Si il reste des requêtes, il faut identifier les coupbles ;-)



 Commentaires   
Commentaire de Serge Delabrosse [ 25/nov./05 15:05 ]
le 22 NOV 05:
===========

On constate encore des appel à cover via speedera ou les comparateurs



img.priceminister.com 206.65.191.206 - - [22/Nov/2005:01:46:40 +0100]
"GET /cover/82147030 HTTP/1.0" 200 3149 "http://achat.ebuyclub.com/Comparateur/PriceMinister-Sonorisation-Automobile-Autre-Constructeur-Sonorisation-Automobile.htm" "swcd/5.2.0040"


m6.priceminister.com 62.23.27.114 - - [22/Nov/2005:01:47:01 +0100] "GET /cover/523568 HTTP/1.1" 200 67862 "-" "libwww-perl/5.65"
m6.priceminister.com 212.23.167.24 - - [22/Nov/2005:01:47:18 +0100] "GET /cover/523568 HTTP/1.1" 200 67862 "-" "libwww-perl/5.65"
img.priceminister.com 212.162.1.214 - - [22/Nov/2005:01:47:22 +0100] "GET /cover/134783630 HTTP/1.0" 200 6250 "-" "swcd/5.2.0040"





img.priceminister.com 212.162.1.214 - - [22/Nov/2005:01:47:25 +0100] "GET /cover/134267030 HTTP/1.0" 200 4387 "http://images.google.com.br/imgres?imgurl=http://priceminister.speedera.net/img.priceminister.com/cover/134267030&imgrefurl=http://www.priceminister.com/navigation/default/category/113216/l1/U/noicon/false&h=130&w=129&sz=5&tbnid=dXLahFh7VxIJ:&tbnh=85&tbnw=84&hl=pt-BR&prev=/images%3Fq%3Dlotr%2Bspectre%26svnum%3D10%26hl%3Dpt-BR%26lr%3D%26sa%3DG&frame=small" "swcd/5.2.0040"

img.priceminister.com 82.225.39.112 - - [22/Nov/2005:01:47:25 +0100] "GET /cover/146039430 HTTP/1.1" 200 2998 "http://www.priceminister.com/trc/casques-2.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; fr) Opera 8.50"
i


www.priceminister.com 212.195.196.78 - - [22/Nov/2005:01:49:47 +0100] "GET /navigation/default/category/104037/noicon/false/rank/2341014B1964014B14238201825A73642801140169735F2864696E146401F4F3F1F1F3F8F60001010201010102010101010201010100270101020102010101010101010101020101010101010100 HTTP/1.1" 200 11388 "http://images.google.fr/imgres?imgurl=http://priceminister.speedera.net/img.priceminister.com/cover/142608530&imgrefurl=http://www.priceminister.com/navigation/default/category/104037/noicon/false/rank/2341014B1964014B14238201825A73642801140169735F2864696E146401F4F3F1F1F3F8F60001010201010102010101010201010100270101020102010101010101010101020101010101010100&h=130&w=129&sz=5&tbnid=AbLgFxZB6scJ:&tbnh=85&tbnw=84&hl=fr&start=2&prev=/images%3Fq%3Ddoc%2Bgyneco%2Bla%2Bclinique%26svnum%3D10%26hl%3Dfr%26lr%3D%26rls%3DGGLD,GGLD:2005-16,GGLD:fr%26sa%3DG" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"


www.priceminister.com 69.134.92.11 - - [22/Nov/2005:01:50:38 +0100] "GET /navigation/search/category/search_clothing/keyword/jordan/ss/70 HTTP/1.1" 200 8528 "http://images.google.com/imgres?imgurl=http://priceminister.speedera.net/img.priceminister.com/cover/164802130&imgrefurl=http://www.priceminister.com/navigation/search/category/search_clothing/keyword/jordan/ss/70&h=100&w=130&sz=4&tbnid=5JqfT0pWtKMJ:&tbnh=65&tbnw=85&hl=en&start=173&prev=/images%3Fq%3DAir%2Bjordans%26start%3D160%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
img.priceminister.com 206.65.191.206 - - [22/Nov/2005:01:50:39 +0100] "GET /cover/164802130 HTTP/1.0" 200 3662 "http://images.google.com/imgres?imgurl=http://priceminister.speedera.net/img.priceminister.com/cover/164802130&imgrefurl=http://www.priceminister.com/navigation/search/category/search_clothing/keyword/jordan/ss/70&h=100&w=130&sz=4&tbnid=5JqfT0pWtKMJ:&tbnh=65&tbnw=85&hl=en&prev=/images%3Fq%3DAir%2Bjordans%26start%3D160%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN&frame=small" "swcd/5.2.0040"
img.priceminister.com 216.200.68.7 - - [22/Nov/2005:01:50:57 +0100] "GET /cover/51424030 HTTP/1.0" 200 8760 "-" "swcd/5.2.0040"


img.priceminister.com 212.162.1.214 - - [22/Nov/2005:01:59:22 +0100] "GET /cover/116260230 HTTP/1.0" 200 12432 "http://images.google.ca/imgres?imgurl=http://priceminister.speedera.net/img.priceminister.com/cover/116260230&imgrefurl=http://www.priceminister.com/offer/buy/2309763/sort0&h=130&w=105&sz=13&tbnid=GLDHAodYj6IJ:&tbnh=85&tbnw=68&hl=en&prev=/images%3Fq%3Dde%2Btom%2Btom%2Bet%2Bnana%26start%3D40%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN&frame=small" "swcd/5.2.0040"
img.priceminister.com 83.152.201.141 - - [22/Nov/2005:01:59:30 +0100] "GET /cover/165625730 HTTP/1.1" 200 5157 "http://www.priceminister.com/trc/118366-1.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
@


[Wed Nov 23 14:04:26 2005] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (961): Can't receive the res
ponse message from tomcat, network problems or tomcat is down (10.150.28.70:8009), err=-104


Commentaire de Edouard Laurent [ 25/nov./05 15:14 ]
http://pricejira.lan/browse/EXP-386
Commentaire de Emmanuel Benmussa [ 13/déc./05 18:30 ]
j'ai encore des images en cover dans les pages TRC , spécial référencement.

elles ont été modifées et les images cover ont été remplacées par photo (avec l'id qui va bien)

en production après le déploiement de la v8.09.

Emmanuel
Commentaire de Sébastien Tournay [ 14/déc./05 15:31 ]
Serge tu peux faire du suivi la dessus suite au déploiement de ce matin ? Vaut aussi valider avec Ranto qu'il avait bien mis en place les nouvelles pages /trc
Commentaire de Serge Delabrosse [ 15/déc./05 16:43 ]
le 15 dec 05 à 16h37 sur phaeton

on observait encore 0,31 % de cover du à des user agent
"hbtools" ou "swcd" voir fichiers joints .

grep "cover" vaccess_log >/data/chrootapache/pmshare/vaccess_log_15_dec_cover.txt

un examen complémentaire est possible sur le fichier

        data/chrootapache/pmshare/vaccess_log_15_dec_cover.txt

 ============ ANNEXE ====================



[adminpm@phaeton logs]$ grep "cover" vaccess_log | wc -l
  11163

==================================================

[adminpm@phaeton logs]$ cat vaccess_log | wc -l
3543492

==================================================

ratio = 11163 / 3543492 = 0,31 %




Commentaire de Serge Delabrosse [ 15/déc./05 16:46 ]
Qu'en penses tu emmanuel ?
Commentaire de Serge Delabrosse [ 15/déc./05 16:58 ]
l'appel à trc / cover compte pour 41% des appel cover .

[adminpm@phaeton pmshare]$ grep trc vaccess_log_15_dec_cover.txt | wc -l
   4663
[adminpm@phaeton pmshare]$ cat vaccess_log_15_dec_cover.txt | wc -l
  11254
[adminpm@phaeton pmshare]$

====================== ANNEXE ====================

img.priceminister.com 81.67.20.211 - - [15/Dec/2005:16:29:14 +0100] "GET /cover/150546430 HTTP/1.1" 200 4016 "http://www.priceminister.com/trc/114762.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
img.priceminister.com 81.67.20.211 - - [15/Dec/2005:16:29:14 +0100] "GET /cover/82365230 HTTP/1.1" 200 4556 "http://www.priceminister.com/trc/114762.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
img.priceminister.com 195.101.248.97 - - [15/Dec/2005:16:29:55 +0100] "GET /cover/165965130 HTTP/1.0" 200 26153 "http://www.priceminister.com/trc/114684.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
img.priceminister.com 195.101.248.97 - - [15/Dec/2005:16:29:56 +0100] "GET /cover/82429630 HTTP/1.0" 200 3299 "http://www.priceminister.com/trc/114684.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
img.priceminister.com 195.101.248.97 - - [15/Dec/2005:16:29:56 +0100] "GET /cover/161859930 HTTP/1.0" 200 2535 "http://www.priceminister.com/trc/114684.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
img.priceminister.com 195.101.248.97 - - [15/Dec/2005:16:29:56 +0100] "GET /cover/100474730 HTTP/1.0" 200 2481 "http://www.priceminister.com/trc/114684.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
img.priceminister.com 84.4.76.39 - - [15/Dec/2005:16:29:58 +0100] "GET /cover/135790530 HTTP/1.1" 200 2671 "http://www.priceminister.com/trc/divers-4.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51"
img.priceminister.com 84.4.76.39 - - [15/Dec/2005:16:29:58 +0100] "GET /cover/135787530 HTTP/1.1" 200 3640 "http://www.priceminister.com/trc/divers-4.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51"
img.priceminister.com 84.4.76.39 - - [15/Dec/2005:16:29:58 +0100] "GET /cover/144508230 HTTP/1.1" 200 7303 "http://www.priceminister.com/trc/divers-4.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51"
img.priceminister.com 84.4.76.39 - - [15/Dec/2005:16:29:58 +0100] "GET /cover/144537230 HTTP/1.1" 200 3348 "http://www.priceminister.com/trc/divers-4.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51"
img.priceminister.com 84.4.76.39 - - [15/Dec/2005:16:29:58 +0100] "GET /cover/104317530 HTTP/1.1" 200 2404 "http://www.priceminister.com/trc/divers-4.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51"

Commentaire de Swan Desportes [ 27/déc./05 16:16 ]
Bonjour,

Maintenant que les TRC ont été corrigées et mis en production, il faudrait comprendre d'où viennent les appels de cover restants. Pourrait-on identifier les referers pour savoir quels sont les sites qui font appels à cover et par quel biais ils ont récupéré ces URL ?

Merci
Commentaire de Antoine Koener [ 23/janv./06 12:09 ]

Dans vaccess_log, je trouve des demandes provenant toujours du user-agent: swcd

75 % viennent du moteur Speedera, swcd est son user-agent.

25 % viennent du cache des images google.

Le responsable est donc Speedera, en voici la preuve: (ligne de log reformattée pour des soucis de lecture)
croix-rouge.priceminister.com 131.194.93.19 - - [23/Jan/2006:01:58:42 +0100]
"GET /navigation/default/category/1360/l1/J/noicon/false HTTP/1.1"
200 9096
"http://images.google.com/imgres?imgurl= ( google images )
http://priceminister.speedera.net/ ( reference d'une page speedera )
img.priceminister.com/cover/77924930&imgrefurl=http://croix-rouge.priceminister.com/navigation/default/category/1360/l1/J/noicon/false
&h=130&w=130&sz=6&tbnid=picCqgArxlph3M:&tbnh=85&tbnw=85&hl=en&start=76&prev=/images%3Fq%3DJem%2Bcartoon%26start%3D60%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.
1; SV1)"

Speedera continue de nous demander des /cover, visiblement nous le lui donnons, il continue à alimenter google...

Est-ce que cette analyse réponds à la question ?
Commentaire de Sébastien Tournay [ 25/janv./06 16:40 ]
On pourrait bloquer le user-agent de speedera pour l'empécher de crawler ? Pour ce qui concerne GOOGLE, j'ai un peu l'impression qu'il faut attendre sa mise à jour.
Je viens de regarder sur les interfaces d'admin de SPEEDERA, nous n'avons plus accès à leurs logs pour voir quelles pages faisaient encore référence à leurs caches.
Commentaire de Antoine Koener [ 15/févr./06 15:54 ]
 On ne controle pas les caches extérieurs.




[EXP-445] apache : augmentation des apache errors (Cf courbe minitor) : analyser Création: 30/nov./05 16:56  Mise à jour: 25/juin/07 18:54  Résolue: 27/févr./06 12:43

Etat: Résolu
Projet: Exploitation
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Justin Ziegler Attribution: Andrei Matyas
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: PNG File apacherror-day-261205.png    

 Description   
Nous n'avons pas de bonne raison d'avoir autant d'apache error.

Il est important de reduire cette courbe afin qu'elle reste pertinente.
La plupart des erreurs proviennent probablement de problemes de dev.
Il faut donc les identifier et les faire corriger en postant un jira pour chaque probleme.

Il y a peut etre aussi des scan de recherche de trous de secu : on pourrait resoudre cela en mettant des redirections vers la home des urls les plus frequement demandees.

 Commentaires   
Commentaire de Sébastien Tournay [ 19/janv./06 15:51 ]
Antoine,

Il faudrait suivre cela du coin de l'oeil pour comprendre et isoler ces erreurs. Je viens de remarquer un pic élevé sur la journée d'hier (cf. attachement). ATTENTION car les logs d'erreur sont archivés que 2 jours
Commentaire de Justin Ziegler [ 22/févr./06 21:15 ]
En fait, j'ai l'impression que le nb d'erreur apache a augmente sensiblement depuis le dernier deploiement...
Commentaire de Sébastien Tournay [ 23/févr./06 09:31 ]
Il semble en effet que plusieurs images référencées dans la V811a ne sont pas présentes. Par exemple :

* /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/camif/images/help/bt1_on.gif.gif
* /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/www/images/auto/dot_black.gif
* /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/francemobiles/images/header/tab_over_home.gif
* /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/www/images/auto/dot_black.gif
Commentaire de Antoine Koener [ 23/févr./06 10:46 ]

Voici les erreurs les plus fréquentes:

Les stats sont extraites du fichier d'erreurs en cours:

c = signifie client denied by server configuration
f = signifie file does not exist.


c 106 bargain
c 106 home
c 106 root_baby
c 106 root_books
c 106 root_clothing
c 106 root_electronics
c 106 root_games
c 106 root_music
c 106 root_sport
c 106 root_vehicle
c 106 root_video
c 106 root_white
c 106 root_wine
c 106 tab_600
c 106 tab_700
c 106 travel
f 116 /usr/local/apache/htdocs/pmweb/virtualhost-www/navigation?action=search&ss=15&keyword=Soft&category=search_books&category_sub=-1&t=681061&dinsight=343&kwsl=558413
c 128 /usr/local/apache/htdocs/pmweb/virtualhost-bi/maintenance.asis
f 128 /usr/local/apache/htdocs/pmweb/virtualhost-bambinoccasion/maintenance.asis
f 129 /usr/local/apache/htdocs/pmweb/virtualhost-www/affiliation/visuels/video/bannieres_468x60/468x60-comedie.gif
f 140 /usr/local/apache/htdocs/pmweb/virtualhost-www/MSOffice
f 155 /usr/local/apache/htdocs/pmweb/virtualhost-www/_vti_bin
f 184 /usr/local/apache/htdocs/pmweb/virtualhost-camif/content/V811a/front/brand/camif/images/help/bt1_on.gif.gif
f 856 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/camif/images/help/bt1_on.gif.gif
c 1698 403.html
f 3532 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/www/images/auto/dot_black.gif

Il y a des fichiers en gif.gif !
f 184 /usr/local/apache/htdocs/pmweb/virtualhost-camif/content/V811a/front/brand/camif/images/help/bt1_on.gif.gif
f 856 /usr/local/apache/htdocs/pmweb/virtualhost-img/content/V811a/front/brand/camif/images/help/bt1_on.gif.gif


Commentaire de Antoine Koener [ 23/févr./06 10:48 ]

Peux tu jeter un oeil sur ces fichiers manquants ?
Commentaire de Christophe Garcia [ 24/févr./06 12:08 ]
Essentiellement des problèmes de co-branding CAMIF.
Commentaire de Bruno Ballester [ 24/févr./06 17:21 ]
Certaines images comme http://a526.g.akamai.net/7/526/14067/v1/img.priceminister.com/content/V811a/front/brand/camif/images/help/bt1_on.gif sont bien disponibles cependant il semblerait que soient également hébergées en double sur le serveur des images se terminant par des "gif.gif".
Commentaire de Andrei Matyas [ 27/févr./06 12:43 ]
Effectivement j'ai identifié des appels des images « gif.gif » dans l'application (pour Camif). J'ai corrigé donc le problème.




[EXP-425] insertion des attributs dans les flux Création: 28/nov./05 15:15  Mise à jour: 25/juin/07 18:54  Résolue: 01/juin/06 16:09

Etat: Résolu
Projet: Exploitation
Composants: Etude
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Charles Decaux Attribution: Edouard Laurent
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Duplicate
doublon de EXP-2175 Etude de la refonte des flux produits Résolu

 Description   
Il faudrait être capable de gérer les attributs dans les flux et donc pour cela de traiter de facon indépendante les livres comme vu avec Edouard.

 Commentaires   
Commentaire de Alain Bonneaud [ 19/janv./06 16:11 ]
Voir avec le développement et avec l'équipe BI.

A priori cela existe déjà pour le hightech dans kelkoo




[APP-8714] [1euro] développement événements Création: 26/avr./06 18:38  Mise à jour: 25/juin/07 18:37  Résolue: 03/juil./06 18:27

Etat: Fermé
Projet: Application PriceMinister
Composants: Paiement
Affecte la/les version(s): 9.0.1
Version(s) corrigée(s): 9.0.1

Type: Amélioration Priorité: Majeur
Rapporteur: Martin Iacampo Attribution: Renaud Dierickx
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Word rapport décisionnel 1euro mini spécification fonctionnelle.doc    
Liens des demandes:
Dépendance
est bloqué par APP-10624 [1Euro] Implémenter l'evt "départ ver... Ouvert
bloque DEC-332 [1euro] développement rapport décisio... Fermé
Similaire
similaire à APP-10623 [1Euro / Xiti] Prise en compte du che... Fermé

 Description   
Pour faire suite à la demande de la DG d'un rapport décisionnel, voici les événements à développer et à stocker dans la base.

Le développement est pour "dès que possible" (à priori un mini déploiement après la 9.0.0 ou la 9.0.1).

Voir pièce jointe, rapport décisionnel 1euro mini spécification fonctionnelle.doc

 Commentaires   
Commentaire de Martin Iacampo [ 15/juin/06 16:02 ]
ce serait super intéressant d'avoir ces évènements en place dès l'activation du service, prévu le 28/06 à priori ...
même si le développement du rapport prend encore quelque temps, au moins les évènements seront stockés ...
est-ce toujours considéré comme un DEV prioritaire ?
Commentaire de Arnaud Forgues [ 15/juin/06 16:15 ]
C'est en effet dans la besace du Renaud, qui va tenter de le traiter si le temps le lui permet !
Commentaire de Renaud Dierickx [ 19/juin/06 16:57 ]

J'ai créé les évenements sauf celui "départ vers 1euro" car il est plus compliqué que prévu.

Etant donné le code freeze de la V901, j'ai livré le premier lot d'évènements.

 cvs ci -m "APP-8714 : Store event for 1euro payment event" src/com/babelstore/payment/PaymentConstants.java src/com/babelstore/payment/front/PaymentResponseAction.java src/com/babelstore/payment/front/PaymentResponseCancelAction.java src/com/babelstore/purchase/business/PurchaseBusiness.java src/com/babelstore/purchase/business/PurchaseBusinessBean.java src/com/babelstore/purchase/front/CheckoutPay1EuroCom.jsp
dos2unix: converting file CheckoutPay1EuroCom.jsp to UNIX format ...
Checking in src/com/babelstore/payment/PaymentConstants.java;
/home/cvs/dev/source/src/com/babelstore/payment/PaymentConstants.java,v <-- PaymentConstants.java
new revision: 1.6; previous revision: 1.5
done
Checking in src/com/babelstore/payment/front/PaymentResponseAction.java;
/home/cvs/dev/source/src/com/babelstore/payment/front/PaymentResponseAction.java,v <-- PaymentResponseAction.java
new revision: 1.14; previous revision: 1.13
done
Checking in src/com/babelstore/payment/front/PaymentResponseCancelAction.java;
/home/cvs/dev/source/src/com/babelstore/payment/front/PaymentResponseCancelAction.java,v <-- PaymentResponseCancelAction.java
new revision: 1.8; previous revision: 1.7
done
Checking in src/com/babelstore/purchase/business/PurchaseBusiness.java;
/home/cvs/dev/source/src/com/babelstore/purchase/business/PurchaseBusiness.java,v <-- PurchaseBusiness.java
new revision: 1.166; previous revision: 1.165
done
Checking in src/com/babelstore/purchase/business/PurchaseBusinessBean.java;
/home/cvs/dev/source/src/com/babelstore/purchase/business/PurchaseBusinessBean.java,v <-- PurchaseBusinessBean.java
new revision: 1.392; previous revision: 1.391
done
Checking in src/com/babelstore/purchase/front/CheckoutPay1EuroCom.jsp;
/home/cvs/dev/source/src/com/babelstore/purchase/front/CheckoutPay1EuroCom.jsp,v <-- CheckoutPay1EuroCom.jsp
new revision: 1.12; previous revision: 1.11
done
Commentaire de Renaud Dierickx [ 19/juin/06 17:22 ]
On peut tester les evts sauf celui "départ vers 1euro" qui n'est pas développé... VOIR APP-10624 !!
Commentaire de Renaud Dierickx [ 19/juin/06 18:17 ]
En attendant de résoudre totalement le bug APP-10624, nous avons loggé un evt sur la selection d'1euro.com c'est à dire sur le passage à l'écran "Paiement sécurisé avec 1euro.com"
Commentaire de Cyrille Sarti [ 29/juin/06 15:05 ]
Bonjour,

Pour les évènements 270 et 340, serait-il possible d'avoir le montant de la transaction dans le champ "description" ?

Merci d'avance et bon après midi,
Annabelle.
Commentaire de Martin Iacampo [ 03/juil./06 13:14 ]
Pourriez-vous répondre à la demande du BI avant activation en live ?
Comme ça, les événements seront terminé dès le début ... :-)
Commentaire de Arnaud Forgues [ 03/juil./06 18:07 ]
Renaud ajoute le montant pour l'evenement 340. L'evenement 270 sera traité ultérieurement (un autre JIRA a été ouvert par RED)
Commentaire de Renaud Dierickx [ 03/juil./06 18:27 ]
Le dev est fait : Judd doit integrer cette modification dans la V901.
Commentaire de Patrick Condevaux [ 04/juil./06 17:05 ]
les evenements ont bien l'air d'etre genere toutefois il reste des problemes signales dans le jira APP-10908




Installation Business Objects Production (BIN-15)

[BIN-20] Configuration JK du serveur Tomcat utilisé par BO sur SA tellus Création: 08/déc./05 11:33  Mise à jour: 14/sept./07 16:55  Résolue: 14/déc./05 18:20

Etat: Fermé
Projet: Business Intelligence
Composants: Production
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Majeur
Rapporteur: François Le Lay Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 0 minutes
Temps consacré: 30 minutes
Estimation originale: 30 minutes


 Description   
Décommenter le Connector Coyote/JK dans le fichier server.xml de tomcat, passer le port d'ecoute JK à 8010 au lieu de 8009 pour éviter d'interférer avec JBOSS

 Commentaires   
Commentaire de François Le Lay [ 08/déc./05 11:45 ]
Ranto au niveau de la création du worker bi je propose 8010 comme port :)
Commentaire de François Le Lay [ 14/déc./05 18:20 ]
BO tourne sur tellus! Configuré avec les ports suivants:
HTTP => 7070
JSP => 7043
Shutdown hook => 7010
AJP1.3 => 8010 (pour mod_jk)

Un test a été fait depuis phaeton avec un browser texte sur le port 7070, on obtient bien la page pour se loguer dans l'InfoView.





Installation serveur base de données (BIN-6)

[BIN-44] Résolution problème bloquant Création: 14/févr./06 19:17  Mise à jour: 14/sept./07 16:58  Résolue: 23/mars/06 18:46

Etat: Fermé
Projet: Business Intelligence
Composants: Bug & Improvement
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sous-tâche Priorité: Bloquant
Rapporteur: Agathe Remy Attribution: Patrick Pereira
Résolution: Corrigé  
Estimation restante: 1 heure, 30 minutes
Temps consacré: 1 jour, 6 heures, 30 minutes
Estimation originale: 2 jours


 Commentaires   
Commentaire de Agathe Remy [ 14/févr./06 19:18 ]
Bonjour,

Nous sommes bloqués aujourd'hui par des problèmes de temps d'exécution des mappings d'alimentation journalière du DataMart. Cela empèche la finalisation de la mise en production BI !!! J'aurais donc besoin d'une ressource DBA afin de m'aider à résoudre ce problème.

Merci:-)

Agathe
Commentaire de Sébastien Tournay [ 15/févr./06 09:14 ]
On va mettre Patrick sur le sujet pour te permettre d'avancer dans la mesure ou Edouard gére le déploiement de la V811.
Commentaire de Patrick Pereira [ 16/févr./06 18:13 ]
Listes des actions menées :

- augmentation de la taille des redolog 100 -> 500 Mo => moins de contention au moment des pointes de charges
- alter table et index des tables ODS.ADVERT, DTM.TD_PRODUCT, STM.TF_ADVERT, parallème => on parvient à utiliser plus d'une CPU
- augmentation du nombre de DB_WRITER + parallèlisation des insert => on utilise au maximum les disques.
- diminution du paramètre db_file_multiblock_read_count de 16 à 8 pour diminuer l'utilisation systematique des full table scan.

En plus, Agathe à fortement optimisé la requête.

Conclusion, ça va beaucoup mieux, mais il faut continuer à chercher !
Commentaire de Patrick Pereira [ 23/mars/06 18:46 ]
C'est bon maintenant.




[APP-14297] isoler FAST et oracle : j'ai toujours l'impression que les pages FAST squatent les connexions du pool oracle Création: 15/déc./06 21:18  Mise à jour: 25/juin/07 18:48  Résolue: 25/janv./07 10:16

Etat: Fermé
Projet: Application PriceMinister
Composants: Recherche produit
Affecte la/les version(s): 11.0.0 (Merge et Maintenance)
Version(s) corrigée(s): 12.0.0

Type: Bogue Priorité: Critique
Rapporteur: Justin Ziegler Attribution: Olivier Bourgeois
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Classif1: FAST
Projets PM archivés: Maintenance 12.0.0

 Description   
il me semble important pour la stabilité globale de l'appli de se débarasser de ce probleme.

Actuellement un pb de perf FAST degénère en pb de noManagedCon et plante donc complètement tous les utilisateurs sur toutes les pages !!!
Cela s'est encore produit ce soir !

 Commentaires   
Commentaire de Nicolas Chauveau [ 20/déc./06 10:00 ]
C'est le pb que je t'ai signalé hier en reunion.
Commentaire de Quentin de Chivré [ 27/déc./06 14:16 ]
Analyser plus en détail : effectivement sur les pages faisant appel a FAST, on ne devrait quasiment plus jamais avoir besoin d'accéder à Oracle.

Ce pb avait été identifié il y a qq temps et nous avait permis de voir que chaque page faisait un appel a Oracle pour calculer le nb d'article en panier => Andreï avait changé la façon d'afficher le panier dans le header.
Visiblement le pb est revenu par un autre biais... Infoglue ?
Commentaire de Swan Desportes [ 27/déc./06 15:05 ]
A traiter en priorité au titre de la "RESERVE".
Commentaire de Olivier Bourgeois [ 04/janv./07 15:11 ]
J'ai bien fini par identifier quelques requêtes Infoglue sur SearchMono et AlphaNavigation : elles provenaient d'une mauvaise utilisation de quelques
Phrase dans deux JSPs. Désormais elles feront appel aux données qui sont en cache : c'est déjà ça de moins en requêtes.

En ce qui concerne le calcul du panier, c'est un trade-off entre deux choses : la validité de l'affichage et le nombre de requêtes générées.

Andreï avait supprimé la requête systèmatique en ne faisant une requête qu'après un paiement ou une mise à jour de panier (retrait par ex), cependant dans le cas d'une expiration de panier (par batch donc) les données affichées deviennent invalides : Renaud est donc revenu à la méthode initiale lors d'une modification récente.

Reste un autre point suspect : il y a des requêtes de finder par PK sur USER_ACCOUNT autant de fois qu'il y a d'articles en panier !

FAST me semble innocent dans tout ça.
Commentaire de Quentin de Chivré [ 04/janv./07 19:44 ]
1/ Mauvais usage de Phrase :
ca veut dire que le cas peut se produire dans d'autres JSP ?
Y a t'il un moyen de détecter cela de facon plus générale ?

2/ Panier dans le header:
Pas d'accord avec la modif de Renaud alors... revenir a ce que faisait Andrei !
Quel est le n° de jira corrigé par Renaud ?

3/ Requetes sur user_account :
Pas terrible, a corriger...

4/ FAST :
FAST n'est pas vraiment "innocent" : si FAST ne répond pas, l'utilisateur reclique et reclique a nouveau et accapare des connexions Oracle => famine de connexions pour les autres des que 20 connexions sont bloquées !
solutions :
 - éviter que FAST ne réponde pas
 - et éviter que les pages utilisant FAST n'utilisent aussi Oracle

Commentaire de Olivier Bourgeois [ 05/janv./07 12:19 ]
1/ Pour ça j'ai plutôt modifié PhraseFormat.format : le problème vient de la migration des JSPs après l'unification de Phrase et Label. Ces JSPs utilisent le nom complet de la JSP comme clé de Lexicon plutôt que le nom formatté.

2/ Ok je vais voir ça avec Arnaud alors. Sinon est-ce qu'on ne pourrait pas mettre le nombre d'articles en session ? Il faut tout de même faire attention aux regressions car pour l'instant la collection d'articles est une variable publique de HeaderModel !

3/ Corrigé : il y avait un booléen pour ne pas requêter les informations chronopost mais il ne servait à rien. Avec ce correctif on passe de 3 + nbArticles requêtes à 2 requêtes : une pour la Dynamo et une pour le panier. C'est déjà moins lourd

4/ Vu avec Martin ça paraît plus un problème de dimensionnement et de tuning des serveurs FAST en ce qui concerne le fait que FAST ne réponde pas.
Commentaire de Olivier Bourgeois [ 22/janv./07 17:28 ]
2/ c'est APP-12533
Commentaire de Olivier Bourgeois [ 22/janv./07 18:23 ]
Ok je viens de comprendre le truc : le nombre d'article est bien en cookie dans une variable cart, mais le modèle récupère néanmoins le nombre d'articles depuis la base. Ensuite la jsp du header met à jour la variable du cookie avec la valeur calculée dans le modèle.
L'"optimisation" d'avant ne mettait pas à jour le cookie tout le temps, mais le modèle continuait de requêter la base tout de même.
Alors je pense que l'idée à la base c'était de juste incrémenter décrémenter une variable dans le cookie ?
Commentaire de Olivier Bourgeois [ 25/janv./07 10:16 ]
Je ferme ce Jira et j'en créée un nouveau pour implémenter une nouvelle optimisation du mode de calcul des articles en panier :
APP-14775




[APP-14279] perf fiche produit : dégradation lente depuis juin 2006 Création: 15/déc./06 10:00  Mise à jour: 09/mai/08 09:33  Résolue: 24/avr./08 11:04

Etat: Fermé
Projet: Application PriceMinister
Composants: Perf
Affecte la/les version(s): 11.0.0 (Merge et Maintenance)
Version(s) corrigée(s): 21.0.0

Type: Bogue Priorité: Critique
Rapporteur: Justin Ziegler Attribution: Manuel Sadok
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg     JPEG File screenshot-2.jpg    
Liens des demandes:
Similaire
similaire à APP-13629 Perf : les fiches produits comportant... Fermé
similaire à APP-14281 [POST DEPLOY] perf d'affichage nav pa... Fermé
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-14898 Quick-fix avant refonte BreadCrumbs Sub-improvement Fermé Manuel Sadok  
APP-14899 Refonte du CDF Sub-improvement Fermé Alexandre Garnier  
Pays:
FRA - France
Site: Prod
Projets PM: Performances
Classif1: TECH

 Description   
Visible sur la courbe http://intra.priceminister.com/stats/mrtg/phaeton/requestcatprod.html
=> regarder l'annee entiere !

 Commentaires   
Commentaire de Justin Ziegler [ 18/déc./06 14:53 ]
Je constate de plus que nos serveurs historiques supportent de moins en moins bien la monté en charge.
Ainsi, sur tellus (4 CPU xeon hyperthreadé à 1,4 GHz) on a du mal à dépasser les 100 utilisateurs simultané sans que la FP prenne 2s en temps de génération. De plus, cela semble fluctuer fortement...

On observe ce même phénomène de fluctuation sur nos serveurs plus récents bi-pro hyper thread / 64 bit !
La FP serait elle devenue particulièrement complexe / couteuse ?

NB : je n'ai pas l'impression que cela vienne de la base, meme si j'ai l'impression que la requete de selection des annonces pour une FP donnée pourrait être plus efficace que ce qu'elle est aujourd'hui.

J'ai posté un autre jira ces derniers concernant la perf de la FP dans le cas ou il y a de nombreuses annonces...
Commentaire de Quentin de Chivré [ 27/déc./06 14:13 ]
Pour le pb des FP avec trop d'annonces, il faut
1/ limiter le nb d'annonces retournées au nb d'annoncs affichées
2/ ajouter une requete de comptage des annonces associées a la FP (s'assurer qu'on a le bon index)

On ajoute une requete pour générer la page mais si elle est bien optimisée, pas de pb.

D'autre part, analyser la génération de cette page en détail :
- activer les logs de mesure des temps d'execution (TimeLogger ?)
- nb de requetes
- plans d'executions
- ...
Commentaire de Nicolas Chauveau [ 25/janv./07 15:30 ]
Doublon ?
Commentaire de Manuel Sadok [ 31/janv./07 12:16 ]
Effectivement, les FP qui ont beaucoup d'annonces peuvent, à l'heure actuelle, induire un problème de performance étant donné la manière dont est exécutée puis traitée la requête. Cependant, les FP ayant 600 annonces ne sont pas les plus nombreuses sur le site et ne peuvent expliquer à elles seules le problème de perf rencontré.

En regardant de plus près les modifications apportées à la FP sur la période durant laquelle les problèmes de performance ont commencé à être importants, on peut remarquer l'ajout du bloc Pangora et d'importantes modifications du CDF.

1/ En m'intéressant à Pangora et à ses implications sur l'application (hors communications AJAX), il apparait qu'il fait du travail inutile en doublon. D'un point de vue plus technique, au niveau du BaseProductModel :
1-a/ Le ProductDetail (avec attributs) est re-calculé (d'où requêtes BDD) alors qu'il existe déjà au sein de la même instance du model.
1-b/ Il y a un matcher sur l'arbre d'ancienne navigation pour retrouver le chemin de navigation du produit. Or c'est ce que fait précisément le BreadCrumbsModel déjà chargé. Il y aurait clairement une mutualisation intéressante à faire à ce niveau là, d'autant plus qu'à l'heure actuelle Pangora utilise uniquement l'ancienne navigation et non la nav par filtre, qui, à terme, sera la seule à être mise à jour.

2/ Le point précédent permet d'aborder une autre cause possible des dégradations de performance : le CDF. Dans ce cadre, il est intéressant de regarder le BreadCrumbsModel :
2-1/ Pour retrouver le CDF, il y a tout d'abord un matcher qui va chercher dans l'arbre de nav par filtre. Si le matching précédent ne ramène aucun résultat, un nouveau matcher est créé pour aller chercher, cette fois-ci, dans l'arbre d'ancienne navigation. Pour chacun de ces matcher, il y a un ProductDetail (avec attributs) de créer. Il pourrait déjà être intéressant de ne le calculer qu'une seule fois ! De plus, la nav par filtre n'en étant encore qu'à ces débuts, dans la quasi-totalité des cas on effectue donc ce double matching.
2-2/ La génération du tag XITI utilise désormais exactement la même logique que le CDF. Autrement dit, on double l'exécution de ce qui a été détaillé précédemment à chaque affichage de la FP. Il serait pertinent de ne faire tout le travail de matching de navigation une seule fois pour la génération du CDF et de XITI.
2-3/ De la même manière, le résultat de cette centralisation pourrait être utilisé par Pangora et donc alléger le traitement fait dans le BaseProductModel. De plus les données sont plus cohérentes que celles utilisées à l'heure actuelle.

3/ Au vu des 2 points précédents, un rapide calcul nous montre que lors d'un affichage d'une FP, on construit déjà 6 fois le même ProductDetail !
Outre une amélioration potentielle en mutualisant les traitements actuels, il est intéressant de se pencher sur la construction du ProductDetail. Le constructeur de ce dernier prend un Productnfo en paramètre. Or, ce ProductInfo n'est pas récupéré à partir d'un finder, mais à partir d'une requête applicative. La requête utilisée (ProductInfoSearchQuery) est également utilisée pour la recherche d'un produit en BO. Une jointure est faite entre product et user_account afin de ramener un ProductSubmitterInfo, qui contient en plus des données produits des informations sur le soumetteur de la fiche. Or, en FO, ces données sur le soumetteur ne sont pas utiles, d'autant plus qu'un cast en ProductInfo (au moment de la construction du ProductDetail) ne permet pas de les conserver. Un finder serait donc bien plus performant pour l'utilisation FO.

Il pourrait déjà être intéressant d'effectuer ces optimisations afin de voir l'impact sur les perf de la FP.
Commentaire de Quentin de Chivré [ 31/janv./07 13:13 ]
Je suis partant !


En ce qui concerne le BreadCrumbsModel, j'avais jeté un oup d'oeil il y a qq temps et avait été assez horrifié.... Bcp trop de calculs faits dedans et de connaissance du reste de l'application est centralisé la. Ce model devrait construire un chemin avec des "placeholders" alimentés selon le contexte
=> la même remarque que j'ai pu faire sur le TemplateModel qui dans le cadre des blocs promo a bcp trop de connaissance de son contexte d'execution. Il faut inverser la logique...
=> ainsi, quand on est dans le contexte d'une FP ou d'une nav, c'est le model associé qui doit charger les données et feeder le NreadCrumbsModel avec un sous-chemin servant a compléter le chemin de base


Suis-je clair ? Je pense que ce truc a été codé a l'arrache par Andrei et mérite une re-conception !
Commentaire de Manuel Sadok [ 01/févr./07 16:14 ]
Un quick-fix permettant de limiter certains traitements inutiles est fixé pour la V13.0.0 (1ère sous-tache) avant une refonte plus globale du mécanisme de génération du CDF fixée, pour le moment, pour la V14.0.0 (2ème sous-tache).
Commentaire de Manuel Sadok [ 10/mai/07 10:17 ]
En regardant la même courbe a l'heure actuelle, le quick-fix qui a été déployé fin février semble avoir été efficace.
Commentaire de Justin Ziegler [ 10/mai/07 11:37 ]
Oui, sur cette courbe, on observe une amelioration à cette date là, mais difficile d'être certain que c'est grace a ton fix.

On peut aussi regarder les courbes coté SA :

http://intra.priceminister.com/jbossofferbuy.html
http://intra.priceminister.com/stats/mrtg/salus/offerbuymaxresponsetime.html (salus est representatif)
http://intra.priceminister.com/stats/mrtg/sol/offerbuymaxresponsetime.html (sol également)
http://intra.priceminister.com/stats/mrtg/terra/offerbuymaxresponsetime.html (terra aussi)
Commentaire de Justin Ziegler [ 10/mai/07 11:47 ]
la différence entre les courbes SA et la courbe initiale vue du serveur web est la suivante :
1/ sur le serveur web : on effectue une requete sur une fiche produit précise, toujours la meme et on mesure le temps de reponse.
2/ sur les SA, on regarde les n dernieres lignes de log, et on graphe le max du temps de generation des fiches produit

en regardant moi meme les log applicatif, j'ai constaté que seules certaines FP étaient très mauvaises : celle avec bcp d'annonce. Il faudrait voir si c'est toujours le cas. J'avais fait un jira avec toute l'analyse à l'époque...
Commentaire de Manuel Sadok [ 24/avr./08 11:04 ]
Je ferme ce Jira qui n'a plus de raison d'être : la sous-tache qui lui est associée doit faire l'objet d'un autre Jira à part.




[APP-7653] Impossible de récupérer une valeur d'attribut afin de l'utiliser dans les spécifications Création: 27/févr./06 16:56  Mise à jour: 25/juin/07 18:35  Résolue: 21/août/06 18:43

Etat: Fermé
Projet: Application PriceMinister
Composants: Mise en vente
Affecte la/les version(s): 8.1.1
Version(s) corrigée(s): 9.0.3

Type: Amélioration Priorité: Majeur
Rapporteur: Yassine Mouhammadou Attribution: Judd OSullivan
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File fiche_tech.JPG    

 Description   
Dans le formulaire de mise en vente, on renseigne des champs de saisie libre (input), des menus déroulant (select), des cases à cocher (checkbox) etc.
Pour certains types de produits, on crée une fiche technique, à l'aide des spécifications (étendue), dans le format correspondant.
Les infos saisies dans un input sont bien récupérés et sont bien affichées dans la fiche technique ; par contre, quand il s'agit des checkbox ou des select, ce n'est pas la valeur choisies qui s'affichent mais l'id correspond.

Voir l'imp. écran.

Merci

 Commentaires   
Commentaire de Martin Sudmann [ 28/févr./06 13:45 ]
ce ne serait pas plutôt toi, les formulaires G3 ?
Commentaire de Yassine Mouhammadou [ 28/févr./06 14:08 ]
Genevieve dit:
je viens de travailler sur ce bug et j'ai vu que c'etait un pb de conf.
En fait pour nous faire comprendre le problème, Yassine a changé la cellule de format de spec en question (format "Soumission Imprimantes" en Integ par ex).

Pb constaté :
Lorsque l'on crée une cellule "spécification" dans le format, on met dans l'alias le nom du paramètre du champ en question. Or, si le champ est un select (checkbox), on affiche l'id category au lieu de la valeur sélectionnée (cochée).

Ce qui est fait actuellement pour contourner le pb :
Par le biais d'une fonction en Javascript, on stocke dans un champ hidden le label correspondant à l'id de la valeur sélectionnée Et on fait appel à ce dernier dans le format pour les spécifications.

Ce que l'on souhaiterait :
Eviter de passer par un champ intermédiaire, car cela devient lourd à gérer et difficile à mettre en place en 3G Light.
Commentaire de Yassine Mouhammadou [ 28/févr./06 14:14 ]
Voici un exemple du controunement fait dans les formulaires en question :

<tr>
<td>Format maximal</td>
<td><select $form.select("imprimante_format", $form.value("imprimante_format"))
style="width:80%"
id = "$form.getControlName("imprimante_format")"
onChange = "javascript:sel(document.getElementById('$form.getControlName("imprimante_format")').name, document.getElementById('$form.getControlName("imprimante_format_hide")').name);">
$form.options("imprimante_format", $form.value("imprimante_format"))
</select>

<input $form.input("imprimante_format_hide", $form.value("imprimante_format_hide")) type="hidden" id = "$form.getControlName("imprimante_format_hide")">
</td>
</tr>

<script>
sel(document.getElementById('$form.getControlName("imprimante_format")').name, document.getElementById('$form.getControlName("imprimante_format_hide")').name);
</script>


                    -------------------------------------------------------------------------------------


function sel (chselect, chhidden) {
document.frmSubmit.elements [chhidden].value = document.frmSubmit.elements [chselect].options [document.frmSubmit.elements [chselect].selectedIndex].text;
}
Commentaire de Quentin de Chivré [ 27/juil./06 20:22 ]
A chiffrer suite a tout ca :

De : Quentin de Chivré [mailto:quentin.dechivre@priceminister.com]
Envoyé : mercredi 26 juillet 2006 18:11
À : 'judd.osullivan@priceminister.com'
Cc : 'mostafa diane'
Objet : TR: Besoin d'aide pour avancer sur le site Espagne.
Importance : Haute


Il faudrait enqueter la dessus et chiffrer rapidemment une solution :
http://pricejira.lan/browse/APP-7653
 
 - a priori côté import il suffit, quand une cellule est mappée sur une spec, d'utiliser le label de la catégorie pour remplir la spec (plutot que les attributs qui lui sont attachés) Ca parait cohérent ?
 
 - côté formulaire pour reselectionner en cas d'erreur la bonne valeur, la je ne sais pas...


Judd, tu peux me répondre la dessus ? Yassine peux t'expliquer le probleme plus en détail si besoin.
 
Merci
 
Q.
 

--------------------------------------------------------------------------------

De : Jérôme VIVIES [mailto:jerome.vivies@priceminister.com]
Envoyé : mardi 25 juillet 2006 16:59
À : quentin.dechivre@priceminister.com
Cc : 'Ariane Baldinger'
Objet : Besoin d'aide pour avancer sur le site Espagne.
Importance : Haute


Quentin,
 
Nous sommes en train de passer beaucoup plus de temps que prévu sur le paramétrage de la mise en vente de certains produit CNet, du fait que nous devons manipuler beaucoup d'attributs, et surtout toutes les spécifications qui vont avec. La gestion des spécification implique des "bidouilles" très consommatrices de temps.
 
En bref, ce jira devient très prioritaire à nos yeux :
http://pricejira.lan/browse/APP-7653
 
Est-il très coûteux à réaliser, et serait-il possible de le faire réaliser rapidement ?
 
Si non, saurais-tu nous suggérer d'autres solutions (par exemple : ne plus remplir les spécifications parce qu'elles seront abandonnées lors de la refonte de la base produit ?)
 
Dis-nous ce que tu en penses.
 
 
-- J.
________________________
J é r ô m e V I V I E S
http://www.priceminister.com

 
Commentaire de Judd OSullivan [ 04/août/06 19:00 ]
Le problème est que la valeur renvoyé par le formulaire n'est pas le texte selectionné mais le category_id de noeud dans l'arbre soumission. La solution la plus bête est de remplacer les category_ids dans les 'option value' de dropdown avec la valeur texte. Mais si on fait ca on casse le type advert_cell "mapping via reference de categorie" (CATEGORY_REF_MAPPING).

Ma solution est de préciser dans la cellule que la valeur est un category_id et n'est pas de texte pur. Donc dans un mapping, soit on ajout une 'Destination : Specification via categorie reference", soit on ajout un checkbox qui precise que la vrai valeur se trouve dans l'arbre de categorie.

J'en parlerai avec l'équipe param lundi pour valider ca.

C'est un demi-journée de dev.
Commentaire de Quentin de Chivré [ 07/août/06 10:03 ]
Ca n'est pas forcément pour les specs, on peut l'utiliser pour autre chose (en fait n'importe quel type de mapping existant)
Le CATEGORY_REF_MAPPING est tres spécifique car il prend le contenu de la catégorie trouvée et le mappe sur "le produit" (pas une colonne ou un attribut donné)

La il s'agit d'une source de données pouvant être mappée sur n'importe (?) quelle destination existante. J'ai l'impression que c'est plus un mécanisme de formulaire qu'un mécanisme d'import. En fait, si on crée un mécanisme type mapping, il faut se demander a quoi il sert dans un contexte import pur, sans formulaire.
Commentaire de Judd OSullivan [ 07/août/06 10:57 ]
Déjà le CATEGORY_REF_MAPPING n'a pas de sens dans un contexte import pur. En plus le problème est unique à la création des specs selon l'équipe param.
Je vois difficilement comment on peut changer le mécanisme de formulaire pour corriger ce problème. C'est comme j'ai expliqué dans ma commentaire de 4 août, on utilise les données de dropdown dans 2 cellule : une qu'a besoin un category_id, l'autre qui a besoin d'un bout de texte. Ce que je propose est comme ce que tu as proposé au début :

"il suffit, quand une cellule est mappée sur une spec, d'utiliser le label de la catégorie pour remplir la spec"

Donc moi je propose d'indiquer dans la cellule que la valeur données n'est pas de texte mais c'est un category_id ou on peut trouver le texte.
Commentaire de Judd OSullivan [ 10/août/06 18:41 ]
Solution validé avec Jerome :
1/ Pour répondre à la besoin immediate : Creation de la destination 'Specification via reference de categorie' qui prend un category_id est qui met la valeur de le label de category dans la specification.
2/ Pour répondre aux futures besoins : Creation de la destination 'Variable via reference de categorie' qui prend un category_id est qui met la valuer de la libellé du category dans la variable préciser.
Commentaire de Judd OSullivan [ 21/août/06 18:43 ]
Dev est fait.
Commentaire de Fabien Farache [ 06/sept./06 14:59 ]
ok... vu avec YAM
(en integ)




[DEC-429] transformation des PMV crédités non activés Création: 31/août/06 15:46  Mise à jour: 14/sept./07 14:55  Résolue: 26/sept./06 12:45

Etat: Fermé
Projet: Reporting
Composants: Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Critique
Rapporteur: Alexandra Viravaud Attribution: Agathe Remy
Résolution: Corrigé  
Estimation restante: 2 heures
Temps consacré: Non spécifié
Estimation originale: 2 heures

Pièces jointes: Microsoft Excel pmv_activation_2006-09-25.xls    
Pays:
FRA - France

 Description   
Salut,

nous avons fait partir en mai dernier un mail sur toutes les personnes qui détiennent un PMV crédité non activé (9665 membres). Nous souhaiterions savoir, parmi les personnnes qui ont recu ce mail combien ont au jour d'aujourd'hui un PMV crédité activé.

Théoriquement, la requête est prête :
http://pricejira.lan/browse/DEC-307

ll suffit d'ajouter le champ PMV crédité activé.

Merci
Alexandra

 Commentaires   
Commentaire de Agathe Remy [ 01/sept./06 19:42 ]
A voir si ce n'est pas trop long...

Merci:-)
Commentaire de François Le Lay [ 26/sept./06 12:45 ]
Ci-joint l'extract des personnes contactées en Mai concernant leur PMV inactivé.
1607 sur les 9665 ont activé leur PMV.
Commentaire de Alexandra Viravaud [ 12/oct./06 11:47 ]
Salut Mohammed,

est-il possible de récupérer le nb de paniers, le CA, la com, le nb de nouveaux acheteurs et le nb d'acheteurs générés par le mail PMV crédités non activés (via BI par exemple) ?

Merci.
Alex




[BIN-294] [Finance] : Validation rapports PMV (Wallet by user et Wallet operations by user) Création: 22/févr./07 13:39  Mise à jour: 14/sept./07 17:37  Résolue: 09/août/07 17:20

Etat: Fermé
Projet: Business Intelligence
Composants: Finance
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Philippe Favrot Attribution: Romain Czornomaz
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel 0 - Wallet_operations_by_user (19 fev 07 YTD).xls     File debit_achat_20060731.csv     File debit_achat_20070424.csv     Microsoft Excel Wallet_by_user (requête au 21 fev).xls    
Pays:
FRA - France

 Description   
Agathe,

j'ai deux soucis avec ces rapports :

1 - réconciliation des mouvements entre Titan et BO

le rapprochement des cumul journaliers des mouvements entre Titan et BO fait ressortir un écart de 293,58 ¿ pour la journée du 31 juillet 06 pour le type de mouvement "Debit_purchase" (voir fichier excel joint / onglet "wallet operations by type / cellules avec rouge).

2 - réconciliation entre le solde cumulé des PMV déterminé avec le rapport "wallet operation by user" et celui donné par le rapport "wallet by user".

- requête en date du 21 février ==> solde des PMV selon "wallet_by_user" = 2 432 409,98 ¿ (voir fichier joint)
- le total des mouvements au 20 février (y compris cette journée) selon "wallet operations by user" donne un solde de 2 408 505,86 ¿
soit un écart de l'ordre de 23 k¿

A ta dispositin pour en parler
Philippe



 Commentaires   
Commentaire de Agathe Remy [ 27/avr./07 18:10 ]
Philippe,

Je viens d'investiguer sur le premier problème.
En fait, il s'agit d'un bug applicatif qui a laissé des opérations en statut 'SUBMITTED' alors que l'évènement de finalisation ('COMPLETION') avait eu lieu.
Et comme les grands esprits se rencontrent, ce bug vient d'être corrigé lors du déploiement de la V14 et devrait être pris en compte dans les rapports BI début mai.

Cordialement,
Agathe
Commentaire de Philippe Favrot [ 02/mai/07 14:41 ]
Bonjour,
en fait je ne suis pas sur de bien comprendre ; s'il s'agit d'un bug applicatif pourquoi les opérations en question seraient-elles traitées de manière différente entre BO et Titan ?
Ce matin, j'ai travaillé sur les mois de février, mars et avril : il y a également des écarts entre BO et Titan pour les journées suivantes :
      - 20 février / crédit BO - autre crédit :
               Titan : 3 240,33 ¿
               BO : 3 799,43 ¿
     - 24 février / débit BO - remboursé à tort :
               Titan : 42 ¿
               BO : 32 ¿
     - 21 mars / débit BO - remboursé à tort :
               Titan : 173,93 ¿
               BO : 183,93 ¿
     - 24 avril / débit achat :
               Titan : 25 221,28 ¿
               BO : 24548,21 ¿
Philippe
Commentaire de Philippe Favrot [ 02/mai/07 19:07 ]
L'utilisation du rapport "wallet operations by user" permet de traiter les écarts des 20 / 24 février et du 21 mars.
En revanche, celui du 24 subsiste ; tu peux regarder STP.
Merci
Philippe
Commentaire de Romain Czornomaz [ 10/juil./07 15:24 ]
Philippe,

Voici la picèe jointe comprenant les operations de "debit achat pour la journée du 31 Juillet 2006.

Romain
Commentaire de Romain Czornomaz [ 10/juil./07 15:25 ]
Philippe,

Voici la picèe jointe comprenant les operations de "debit achat pour la journée du 24 Avril 2007.

Romain




[APP-26706] [META-TACHE] Modification des tracking sites-under + tracking e-mails questions Création: 02/oct./09 11:45  Mise à jour: 01/oct./10 16:12  Résolue: 29/sept./10 12:02

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 78.0.0 (CTN-TU)

Type: Tâche Priorité: Majeur
Rapporteur: Fabrice Feugas Attribution: Dispatcher (Pôle CTN)
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Pièces jointes: PDF File SU_supp_t_40-20091002.pdf    
Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
APP-26113 Tracking Question à un vendeur - t=40 Sub-new feature Fermé Dispatcher (Pôle CTN)  
APP-26796 Faire remonter la comm sur articles ... Sous-tâche Fermé Damien Dorizy  
APP-26797 Ouvrir l'accès aux partenaires à notr... Sous-tâche Ouvert Patrice Boulanger  
APP-26798 Désactiver les t = concernés par les ... Sous-tâche Fermé Mathilde Caby  
APP-26799 Il y a du t= dans l'e-mail de félicit... Sub-bug Fermé Renaud Dierickx  
APP-26800 Modifier la page affiliation Sous-tâche Fermé Carole Boucheny  
APP-26842 Modification du rapport BI : France->... Sous-tâche Fermé Cyril Tanneau  
APP-26843 Modification des TAG des plateformes ... Sous-tâche Fermé Carole Boucheny  
APP-26926 Modification de l'image sur la page d... Sous-tâche Fermé Olga Costa  
APP-26956 Ouverture de l'accès BO pour la désac... Sous-tâche Fermé Stéphane Eccli  
APP-26957 Modification rapports clubic Sous-tâche Fermé Cyril Tanneau  
APP-26967 Modification du TAG Zanox pour S'alig... Sous-tâche Fermé Olga Costa  
APP-27074 Affiliation: Modification du TAG Effi... Sous-tâche Fermé Olga Costa  
APP-27247 Enlever tous les "t=40" des e-mails q... Sous-tâche Fermé Habib-Sylvain Gourguet  
Pays:
FRA - France
Projets PM: *** RESERVE ***
Projets PM archivés: Tracking affiliation

 Commentaires   
Commentaire de Fabrice Feugas [ 06/oct./09 15:35 ]
Le planning en P.J
Commentaire de Ghislain Gridel [ 06/oct./09 15:46 ]
attention, il ne faut pas désactiver les t= de clubic comme indiqué dans le planning mais seulement le rapport automatique BI, sous condition que clubic accepte le nouveau modèle de rémunération; Mathieu vous tiendra au courant.
Commentaire de Ghislain Gridel [ 06/oct./09 15:47 ]
Par ailleurs, il n'existe pas de tag clubic.
Commentaire de Fabrice Feugas [ 06/oct./09 15:50 ]
ok c'est noté.
Commentaire de Fabrice Feugas [ 14/oct./09 15:34 ]
Présentation du projet dans cette page : http://pricewiki.lan/Wiki.jsp?page=Tracking%20afiliation%20%28Sites%20Under%20%2B%20emails%20question%29
Commentaire de Ghislain Gridel [ 22/oct./09 16:06 ]
Bonjour,
clubic a accepté le changement de rémunération. Le contrat est en cours de rédaction.


Peut-on modifier le rapport automatique svp ?
PriceMinister : Partner - Weekly revenue by tracking group
PriceMinister : Clubic - Appel à facture mensuel

Il faut modifier :
- le VA capturé en commission capturée
- La rémunération de 8% du VA capturée à 57.5% de la commission capturée

Le nombre de paniers ne change pas.

Merci !

Ghisalin
Commentaire de Fabrice Feugas [ 22/oct./09 18:25 ]
Ok Ghisalin !

Peux-tu (ou Mathilde) faire un sous-JIRA avec la demande bien précise de ce que vous souhaitez modifier dans le rapport, pour quelle date, et l'attribuer au B.I ?

Merci.
Commentaire de Fabrice Feugas [ 22/oct./09 18:46 ]
Les changements (nouveaux tags et désactivation des codes de tracking) seront effectifs à partir du 01/11 si on intervient sur le BO la veille.

Le système basculera au redémarrage serveur.

Merci.




[MeV] Migration 4G Image & Son (APP-30514)

[APP-30535] [MeV] Amplificateurs 4G Création: 29/juil./10 15:20  Mise à jour: 05/oct./10 14:54  Résolue: 05/oct./10 14:54

Etat: Fermé
Projet: Application PriceMinister
Composants: Mise en vente
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 78.1.0

Type: Sous-tâche Priorité: Majeur
Rapporteur: Simon Stevant Attribution: Simon Stevant
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Projets PM: MEV - Image et Son

 Commentaires   
Commentaire de Simon Stevant [ 29/juil./10 16:02 ]
Passage du formulaire MeV 3G au formulaire 4G pour le type Amplificateurs.
Formulaire effectué sur la plateforme DEV, les tests de soumissions ont été effectués, formulaire opérationnel en Dev
=>Les détails de la migration sont renseignés sur le Wiki MeV 4G Univers image et son

http://pricewiki.lan/Wiki.jsp?page=MeV%204G%20-%20Univers%20Image%20%26%20Son
Commentaire de Simon Stevant [ 29/juil./10 16:07 ]
Tests de mise en vente effectués aujourd'hui,

Les valeurs d'attributs associées à [ PMA0001000 Amplificateur / Type
 ] n'apparaissaient pas car elles étaient affectées d'une qualification Pierre.
 
=>Le détail des modifications effectuées sur les qualifications est résumé dans le tableur joint à la méta-tâche.

Le formulaire pour le type Amplificateurs est fonctionnel sur DEV 3
Commentaire de Simon Stevant [ 24/août/10 13:49 ]
Envoyé à recetter à la valid et aux commerciaux.
Retours:

- Valid:
- Akai et marrantz sont en doublon dans la liste des fabricants
- Il manque amplificateur classique dans type d'amplificateur.

- Service commercial: RAS

Commentaire de Simon Stevant [ 24/août/10 13:53 ]
@Valid:

Il existait deux valeurs Marantz (PM00001235 et Z01928) mappées sur En-tête fabricant pour le type ampli,
comme aucune des deux n'était portée par un produit, j'ai démappé PM00001235

Même réflexion pour Akai , j'ai démappé P50073
Commentaire de Simon Stevant [ 24/août/10 13:55 ]
La valeur amplificateur classique n'existe pas, faut il la créer?
Commentaire de Nicolas Clais [ 03/sept./10 11:42 ]
Titre exemple à ajouter :

Pioneer VSX819HS - Amplificateur Home Cinéma - 5 x 130 Watts - Décodeurs Dolby True HD et DTS-HD - 3 Entrées HDMI - Argent

Descriptif :

- Puissance RMS : 5 x 130 W (1 kHz, 1% THD, 6 ohms)
- Réponse en fréquence (ligne) : 5 Hz - 100 kHz (+0 / -3 dB)
- Rapport signal-bruit (ligne) : 98 dB
- Convertisseur N/A : 192 kHz / 24 bits
- Convertisseur A/N : 96 kHz / 24 bits
- Bi-Amplification possible

Commentaire de Simon Stevant [ 13/sept./10 11:42 ]
Recette aujourd'hui et étude des valeurs d'attribut en prod:

En tête / fabricant

_ Il faudra ajouter une valeur "Autre fabricant"
_Doublon Akai
_Doublon Marantz
Commentaire de Simon Stevant [ 05/oct./10 10:25 ]
Formulaire terminé




[IMP-7154] probleme import chavetvc Création: 11/oct./10 10:06  Mise à jour: 11/oct./10 15:41  Résolue: 11/oct./10 15:41

Etat: Résolu
Projet: Paramétrage - Import
Composants: Demande commerciale
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Mineur
Rapporteur: Anne Korchia Attribution: Jérome Marianne
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France
Login: chavetvc
Séparateur: Tabulation
Type de traitement:
Mise à jour/création annonces (écrasement)

 Description   
mail pro
PSEUDO / CHAVETVC
DEPUIS QUELQUES MOIS LORSQUE JE VOUS ENVOIE MON
FICHIER IL N'EST PAS ECRASE. LES INVENDUS RESTENT
ENCORE EN VENTE. LES NOUVEAUX SONT EN LIGNES PAR
CONTRE. MERCI DE FAIRE LE NECESSAIRE. CORDIALEMENT.

 Commentaires   
Commentaire de Jérome Marianne [ 11/oct./10 15:41 ]
Le mode Écrasement à été mis sur le profil import apparaissant en front.
Le profil FTP est lui déjà en Écrasement.
Le prochain import via ce biais sera en Écrasement.




[IMP-7202] net-treasure : explosion du stock Création: 18/oct./10 15:45  Mise à jour: 26/oct./10 09:46  Résolue: 26/oct./10 09:46

Etat: Résolu
Projet: Paramétrage - Import
Composants: Support monitoring
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Tâche Priorité: Majeur
Rapporteur: Laurent Payot Attribution: Laurent Payot
Résolution: Corrigé  
Σ Estimation restante: Non spécifié Estimation restante: Non spécifié
Σ Temps consacré: Non spécifié Temps consacré: Non spécifié
Σ Estimation originale: Non spécifié Estimation originale: Non spécifié

Sous-tâches:
Clé
Résumé
Type
Etat
Attribution
IMP-7253 treasure-fr : explosion du stock Sous-tâche Résolu Laurent Payot  
IMP-7254 treasure-es : explosion du stock Sous-tâche Résolu Laurent Payot  
Pays:
GBR - Royaume Uni
Login: net-treasure (UK)
Séparateur: N/A
Type de traitement:
N/A

 Description   
Aujourd'hui on constate une explosion du stock sur FR et UK (pour ES le stock d'aujourd'hui n'apparaît pas encore).

Stock FR:
11/10/2010 366082509
12/10/2010 366354975
13/10/2010 369468701
14/10/2010 368461017
15/10/2010 367992410
16/10/2010 369353769
17/10/2010 370029843
18/10/2010 708833006

Stock UK:
11/10/2010 103135794
12/10/2010 105523082
13/10/2010 105186819
14/10/2010 104682678
15/10/2010 104970342
16/10/2010 105016707
17/10/2010 105196031
18/10/2010 451431350

 Commentaires   
Commentaire de Laurent Payot [ 18/oct./10 15:52 ]
Mail d'information envoyé à param CC Agathe
Commentaire de Laurent Payot [ 18/oct./10 16:21 ]
un premier suspect semble être net-treasure (UK) / treasure-fr (FR) qui a importé le 17 octobre sur UK et FR 13 fichiers de 25 000 lignes et un fichier de 40 000 lignes, à chaque fois avec un stock de 999 :
(13 x 25 000 + 40 000) * 999 = 364 635 000 ce qui correspond à l'augmentation
Commentaire de Laurent Payot [ 18/oct./10 16:52 ]
Jeremy, puis-je mettre toutes les annonces du pro avec un stock illimité? Ou alors à combien? (il met des quantités = 999)
Commentaire de Laurent Payot [ 18/oct./10 16:56 ]
Vu avec Jérémy par téléphone: ok pour quantités illimitées.
Commentaire de Laurent Payot [ 18/oct./10 17:09 ]
UK: donné droit quantités illimitées + modifié format + relancé 43 fichiers manuellement
Commentaire de Laurent Payot [ 18/oct./10 17:13 ]
FR: donné droit quantités illimitées + modifié format + relancé 37 fichiers manuellement
Commentaire de Laurent Payot [ 18/oct./10 17:19 ]
ES: donné droit quantités illimitées + modifié format + relancé 43 fichiers manuellement
Commentaire de Laurent Payot [ 19/oct./10 09:38 ]
Le stock du 18 a explosé avec des fichiers du 17. Il y a un jour de décalage par rapport a l'affichage du BO. Il faut attendre demain pour confirmer le retour à la normale.
Commentaire de Laurent Payot [ 20/oct./10 10:25 ]
Stock toujours au même niveau sur les trois sites.
Commentaire de Laurent Payot [ 20/oct./10 10:34 ]
pour tant net-treasure semble etre le seul suspect. Les quantités des annonces sont bien passées en illimité. Lorsque l'on passe la quantité en illimité est-ce que le stock BI est calculé a partir de la dernière quantité connue? Cela expliquerait la non modification du stock. Je vais faire le test sur (d'abord sur UK) en vidant le stock complètement puis en ressoumettant les fichiers depuis le dernier écrasement.
Commentaire de Laurent Payot [ 21/oct./10 10:40 ]
Le vidage de stock tombe sans arret en erreur et est inutilisable pour vider des stocks importants. Je vais essayer avec Daniel de récupérer la liste des ref annonces par webservices et faire un format pour les effacer.
Commentaire de Laurent Payot [ 22/oct./10 18:12 ]
après quelques péripéties (encodage, aplatissement etc) les stock sont en train d'etre vidés. Déja terminé sur UK. Il restera à relancer les fichiers ultérieurs au dernier écrasement.
Commentaire de Laurent Payot [ 25/oct./10 10:29 ]
Les annonces ont bien été supprimées sur les 3 sites. Retour aux stocks normaux.

163 fichiers du pro relancés manuellement sur le UK.
Commentaire de Laurent Payot [ 25/oct./10 10:57 ]
126 fichiers relancés manuellement sur FR.
Commentaire de Laurent Payot [ 25/oct./10 11:36 ]
162 fichiers relancés manuellement sur ES.
Commentaire de Laurent Payot [ 26/oct./10 09:46 ]
Les fichiers ont bien été traités sur les trois sites. Quantité bien fixée à illimité.




OP de collecte 2010 - import de contacts (CAT-3032)

[CAT-3252] Désabonnement de tous les contacts Création: 28/oct./10 17:38  Mise à jour: 28/oct./10 17:53  Résolue: 28/oct./10 17:53

Etat: Résolu
Projet: Paramétrage - Non Import
Composants: Import de contacts Marketing
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Sub-bug Priorité: Bloquant
Rapporteur: Carole Boucheny Attribution: Carole Boucheny
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Désabonnement aux newletters de tous les contacts.

 Commentaires   
Commentaire de Carole Boucheny [ 28/oct./10 17:42 ]
1/ ANALYSE DU PROBLEME

Jusqu'à présent le partenaire remplissait une colonne par Oui ou Non. Cette colonne était interprétée comme cela de notre côté :
Si Oui --> Abonnement aux newletters Price et Partenaire
Si Non --> Abonnement aux newletters Price

La colonne Oui et Non actuelle correspond en fait à :
Oui --> Abonnement aux newletters Price
Non --> Aucun abonnement

Nous avons donc abonnement :
- de personnes à la NL PM, alors qu'elles n'auraient pas dû l'être.
- de personnes à la NL PM + partenaires alors qu'elles auraient dû être abonnées seulement à la NL PM.

De plus, nous avons en fait 3 cas d'abonnements possibles dans ce jeu :
- Abonnement aux newletters Price
- Abonnement aux newletters Price et Partenaire
- Aucun abonnement


2/ SOLUTION

Reprendre le script utiliser aux derniers problèmes avec le même cas.
--> Patrick a lancé le script
--> L'import pourra donc être relancé et réabonner les personnes comme il se doit
Commentaire de Carole Boucheny [ 28/oct./10 17:44 ]
Voici la procédure qu'avait donné Agathe lors du dernier problème :

Bonjour,

Nature du problème :

Des comptes sont abonnés par erreur aux Newsletters AVAL et VMC
(co-registration mise en place depuis le 30/11/2009) en raison d’un mauvais
paramétrage :

· Lors d’import de jeux concours

· Lors de la création de coupons via WebService


Action correctrice déjà mise en place :

· Correction de la moulinette d’abonnement lors de la création des
coupons via WebService (des comptes sont abonnés tous les jours de cette
manière) livrée le 29/05/2010



Proposition de process pour la correction de l’historique :

· Validation des critères d’identification des « comptes abonnés à
tord » par Benoît TABAKA

· Développement des scripts de correction par les dbas afin de :

o Désabonner les comptes abonnés à tord

o Créer les évènements associés avec une description du type « correction
d’abonnement à tord via batch contact »

· Validation des scripts par Arnaud pour vérifier qu’ils respectent
les règles métiers du site

· Passage des scripts en Production

· Réinitialisation des bases emails chez VMC et AVAL afin de
répercuter ces corrections (génération de fichiers full par l’équipe BI)



Critères d’identification des « comptes abonnés à tord » : (à valider par
Benoît)

· Comptes PM inscrits ou prospects

· Abonnés aux Newsletters AVAL et VMC

· Ayant été abonnés via batch contact (import de jeu concours ou
moulinette webservice coupon)

· Dont la date d’abonnement par batch contact est inférieure à la
date d’abonnement par inscription (si inscrit depuis)



Vous trouverez ci-joint la requête associée (sur la base BI car pb d’évènements
archivés sur la base OLTP).



Je reste à votre disposition si vous avez des questions,

Agathe
Commentaire de Carole Boucheny [ 28/oct./10 17:45 ]
Requête qui avait été utilisée :

SELECT distinct ta_usr_subscription.user_account_id, =
ta_usr_subscription.mail_subscription_id
FROM ta_usr_subscription,
     (select user_account_id, mail_subscription_id, max(creation_date) =
as creation_date
      from dwh.ta_usr_event
      where use_type_code=3D600
      and description like '%Batch contact%'
      and MAIL_subscription_ID in (200,210)-- AVAL et VMC
      and creation_date>=3Dtrunc(to_date('20091130','YYYYMMDD'))
      and creation_date<TRUNC(SYSDATE)
      group by user_account_id, mail_subscription_id
      ) batch_contact_subscription,
      (select user_account_id, mail_subscription_id, max(creation_date) =
as creation_date
      from dwh.ta_usr_event
      where use_type_code=3D600
      and description not like '%Batch contact%'
      and MAIL_subscription_ID in (200,210)-- AVAL et VMC
      and creation_date>=3Dtrunc(to_date('20091130','YYYYMMDD'))
      and creation_date<TRUNC(SYSDATE)
      group by user_account_id, mail_subscription_id
      ) registration_subscription
where =
batch_contact_subscription.USER_ACCOUNT_ID=3Dta_usr_subscription.USER_ACC=
OUNT_ID
and =
batch_contact_subscription.mail_subscription_id=3Dta_usr_subscription.mai=
l_subscription_id
and =
batch_contact_subscription.USER_ACCOUNT_ID=3Dregistration_subscription.US=
ER_ACCOUNT_ID(+)
and =
batch_contact_subscription.mail_subscription_id=3Dregistration_subscripti=
on.mail_subscription_id(+)
and =
batch_contact_subscription.creation_date>nvl(registration_subscription.cr=
eation_date,trunc(to_date('20091129','YYYYMMDD')))
and ta_usr_subscription.USS_STATUS_CODE=3D10 -- abonnement actif
and ta_usr_subscription.MAIL_subscription_ID in (200,210)-- AVAL et VMC
and ta_usr_subscription.creation_date<TRUNC(SYSDATE)
and =
ta_usr_subscription.change_date>=3Dtrunc(to_date('20091130','YYYYMMDD'));
Commentaire de Carole Boucheny [ 28/oct./10 17:53 ]
Le script a été exécuté :

Bonjour.

Le script de désabonnement vient d’être exécuté.
Comme précédemment les abonnements qui ont être fait manuellement après la création du compte contact sont conservés.

Pour les 215 534 autres, ils ont vu leur change_date modifiée à la date du jour et disposent d’un événement dont la description est « JIRA CAT-3252 : suppression d''abonnement crees a tord via batch contact ».

Pour plus d’info le script se trouve sur hercule à l’emplacement suivant : /data/priceminister/manualdeploy/V79_0_1/V79_FR_compte_abonnees_a_tord_JIRA-CAT-3252.sql

 

Patrick.


Le 215 534 correspond aux nombres d'abonnements et non de contact.




[APP-31808] Manque stat réclamations "Annulation" dans fiche-article Création: 16/nov./10 13:57  Mise à jour: 18/nov./10 14:58  Résolue: 18/nov./10 14:54

Etat: Fermé
Projet: Application PriceMinister
Composants: Back-Office
Affecte la/les version(s): 81.0.0 (TX-Q)
Version(s) corrigée(s): 81.1.1

Type: Amélioration Priorité: Majeur
Rapporteur: Habib-Sylvain Gourguet Attribution: Jeremy Maltis
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: PNG File TMP_manque_annul_FA.png    
Pays:
ALL - Tous
Projets PM: CoSAV : Gestionnaire de commande

 Description   
Voir screenshot.

Afin de mieux étudier le profil de chaque utilisateur (et notamment chaque vendeur), il faut ajouter la stat concernant le nombre de réclamations de type "Annulation vendeur" dans la ligne "Claims Achats/Ventes".

Merci d'avance.

 Commentaires   
Commentaire de Habib-Sylvain Gourguet [ 16/nov./10 17:47 ]
Thomas, tu penses que ce JIRA peut être traité en TX-Q ?

Merci d'avance.
Commentaire de Thomas Landru [ 16/nov./10 18:01 ]
Il n'est pas prévu de CoSAV pour la TX-Q et nous avions défini une solution ensemble pour que vous puissiez suivre ces chiffres directement en BI (ce fut le sujet de nombreuses réunions entre nous) donc on ne peut pas s'avancer pour le moment.

On a mis ca dans le fichier d'amélioration en priorité élevée.
Commentaire de Thomas Landru [ 17/nov./10 18:04 ]
Jeremy peux tu livrer ca sur le tronc pour la 81.1.1 ?
Commentaire de Jeremy Maltis [ 17/nov./10 18:17 ]
C'est good !
Commentaire de Habib-Sylvain Gourguet [ 17/nov./10 18:24 ]
Splendide !

Merci pour votre souplesse et votre célérité !
Commentaire de Thomas Landru [ 17/nov./10 18:32 ]
Tu es donc invité à venir détacher les post-it demain matin :)
Commentaire de Arnaud Forgues [ 18/nov./10 11:35 ]
Je déplace ce jira en 81.1.1 (patch post 81.0.0) car déjà corrigé
Commentaire de Habib-Sylvain Gourguet [ 18/nov./10 14:44 ]
Manque la stat côté Acheteur (comme indiqué dans le descriptif du JIRA).

Moins prioritaire que côté vendeur : vous préférez un nouveau JIRA pour la 81.1.1.1 ?
Commentaire de Jeremy Maltis [ 18/nov./10 14:54 ]
D'accord.

je ferme ce JIRA, j'en ai ouvert un autre : APP-31876




[BIN-676] [Validation] : Dossiers image dans univers média Création: 20/mai/10 14:31  Mise à jour: 18/nov./10 18:07

Etat: Ouvert
Projet: Business Intelligence
Composants: BackOffice
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Xavier Fabregat Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous

 Description   
Serait-il possible de créer dans l'univers média des trois pays, des dossiers "Image" et "Image event" identique aux dossiers "Gallery" et "Gallery event", donc avec Image id, Image event id, etc... avec en plus une dimension permettant la différenciation entre les images annonce et les images produit.

 Commentaires   
Commentaire de Agathe Remy [ 20/mai/10 15:12 ]
Bonjour,

Stp, pourrais-tu nous donner un peu de contexte et l'objectif de ta demande?
En effet, les infos que tu demandes n'existent pas...

Agathe
Commentaire de Xavier Fabregat [ 20/mai/10 15:56 ]
Nous souhaiterions faire des rapports quotidiens concernant les images validées,refusées et supprimées par la validation afin de mieux appréhender et améliorer notre métier. Nous souhaiterions par la même occasion, différencier dans ces rapports les images annonce des images produit, ainsi que le nombre d'image utiliser par la validation pour enrichir une fiche produit.
Commentaire de Agathe Remy [ 07/juin/10 17:43 ]
Bonjour Xavier,

- Pour suivre quotidiennement les images validées, refusées et supprimées par la validation, il y a plusieurs moyens de le faire avec l'univers existant (notamment en se basant sur les évènements).

- Pour différencier les images annonce des images produit, nous devons créer de nouvelles informations:-( Il faut prévoir un projet d'alimentation. Ce n'est donc pas faisable facilement. Mais je note le besoin pour essayer de l'adresser lors d'un projet.

- Pour identifier les images utilisées par la validation pour enrichir une fiche produit, il y a certainement moyen d'ajouter facilement l'info dans l'univers. Mais pour cela, il me faudrait un exemple pour identifier la bonne donnée. Stp, peux-tu m'en fournir un?

Merci,
Agathe
Commentaire de Xavier Fabregat [ 17/juin/10 14:29 ]
Bonjour,

En ce qui concerne le suivi des images validées, j'ai un rapport intitulé "Validation images" dans le dossier "Aurelien-Xavier/Au secours" qui n'arrive pas à me convaincre.J'ai retourné l'univers média dans tous les sens, les chiffres obtenus me laisse toujours autant perplexe.Je serais pas contre un début de piste.

Merci
Commentaire de Agathe Remy [ 17/juin/10 15:11 ]
Bonjour Xavier,

En fait, il me faudrait un exemple de fiche produit (Id) avec des images utilisées par la validation pour l'enrichir.

Merci,
Agathe
Commentaire de Aurélien Vergalli [ 21/juin/10 09:29 ]
Bonjour,

Exemple de FP enrichie: ID 439446, enrichie avec images annonce ID 180010471, le 21/06/2010 à 09:25 lors de leur validation.

- images annonce: http://bo.priceminister.com/image_back?action=imageadvertview&advertid=180010471
- images FP (pas d'événement): http://bo.priceminister.com/image_back?action=imageview&productid=439446
Commentaire de Agathe Remy [ 21/juin/10 11:49 ]
Merci Aurélien.

Nous allons donc ajouter la dimension "Gallery source label" dans la classe "Gallery" de l'univers MEDIA.
Pour identifier les image utilisées par la validation pour enrichir une fiche produit, il faudra sélectionner les galeries ayant un "Gallery source label" ="PRICEMINISTER_BACK_OFFICE".

Nous vous préviendrons lorsque cet ajout sera livré en Production.

A votre dispo,
Agathe
Commentaire de Agathe Remy [ 24/juin/10 16:29 ]
Bonjour,

Nous venons de livrer les évolutions de l'univers MEDIA en France, Spain et UK:

- Déplacement des indicateurs dans les classes des dimensions associées pour faciliter leur utilisation (et suppression de la classe Indicators)
- Ajout de la dimension "Gallery source label" dans la classe "Gallery" pour identifier les images utilisées par la validation pour enrichir une fiche produit

Svp, pouvez-vous valider ces modifications?

Je suis à votre dispo si vous avez des questions,
Agathe
Commentaire de Xavier Fabregat [ 25/juin/10 11:56 ]
Bonjour,

Merci pour ces modifications, que je n'arrive toutefois pas encore à exploiter correctement.Je me demandais si une dimension "Gallery Change Label" dans la classe "Gallery Event" ne nous serait pas d'un plus grand secours.De même afin de contrôler et corroborer les rapports, nous aimerions avoir des dimensions "Image ID" et "Product ID" dans la classe "Gallery" qui nous sont familiers et vérifiables dans le BO contrairement à Gallery qui ne nous parle pas.Faut -il faire un autre Jira ou celui-ci peut-il servir de fil de discussion pour tout ce qui concerne l'univers MEDIA.

Merci
Commentaire de Agathe Remy [ 25/juin/10 17:11 ]
Bonjour Xavier,

- Il me semble que l'information "Gallery Change Label" correspond à la dimension "Gallery event type label". Sinon, je ne vois pas à quoi tu fais allusion : stp, est-ce que tu pourrais me donner un exemple?
- Pas de problème pour ajouter la dimension "Image Id" dans l'univers "Gallery". Nous vous préviendrons lorsque cet ajout sera livré en Production.
- Pour la dimension "Product ID", nous ne récupérons pas aujourd'hui les informations relatives aux images produits dans le BI. Il faut prévoir un projet d'alimentation. Mais je note le besoin pour essayer de l'adresser lors d'un projet.

Pas de pb pour continuer via ce JIRA:-)

A ta dispo,
Agathe
Commentaire de Xavier Fabregat [ 28/juin/10 14:44 ]
Bonjour,

Je crains que "gallery source label",ne donne, et c'est à priori le cas sur mes premiers rapports(cf. le rapport "Aurelien-Xavier/Au secours/validation images"), que la provenance de la soumission des images que nous validons.Alors que l'on souhaite comptabiliser les images déjà existantes ou pas sur la fiche quelque soit sa
provenance front ou back, que nous considérons légitime pour être l'illustration de la fiche produit.Il me semble que c'est plus du domaine de l'événement, malheureusement toutes les images que nous validons non pas d'événement, donc pas traçable. Ma réflexion se basait en fait sur l'univers Product event, qui possède des dimensions "product source label" et "Product change label" possédant les mêmes valeurs que "gallery source label", et je pensais obtenir quelque chose de plus probant par ce biais.En fait je recherche la provenance de la validation.

Merci




[BIN-448] [First tracking] : amélioration du rapport Buyer distribution by purchase count and first tracking group Création: 23/mai/08 15:38  Mise à jour: 18/nov./10 18:07

Etat: Ouvert
Projet: Business Intelligence
Composants: Marketing Acquisition
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Mineur
Rapporteur: Thomas Beylot Attribution: Julien Girardet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Liens des demandes:
Similaire
similaire à BIN-405 [Espagne] Demande de Rapport : taux d... Fermé
Pays:
FRA - France

 Description   
Hello

sur ce rapport (que je viens de regarder) je pense qu'on pourrait l'améliorer.

En lui ajoutant le nombre de contact concernés par chaque first tracking (car aujourd'hui nous n'avons que les volumes d'acheteurs sans aucune idée de taux de transfo, indicateur clé de qualité). Je sais qu'on peut les avoir facilement à côté mais ce serait plus simple non ?

Et en ayant la répartition des comptes acheteurs dans le temps, pour savoir à partir de quand un tracking group est rentable (car sinon il nous faut sortir le fichier sur certaines périodes pour trouver le point exact de rentabilité dans le temps).

A votre dispo pour en parler.

Thomas.

 Commentaires   
Commentaire de Agathe Remy [ 26/mai/08 10:59 ]
Bonjour Thomas,

J'ai l'impression que ce que tu demandes reviendrait à migrer le rapport http://intra.priceminister.com/stats/reports/confid/Suivi_Acheteurs/suivi_acheteurs_2008-05-25.txt.gz dans BI en ajoutant la notion de first tracking.
En effet, la rapport "Buyer distribution by purchase count and first tracking group" a pour objectif de donner une image de la répartition des acheteurs par nombre de paniers effectués pour un dispositif de provenance donné (first tracking).
Pour étudier le taux de transfo et la répartition des comptes acheteurs dans le temps, il ne s'agit plus d'une image, mais d'un suivi de l'activité.
D'ailleurs il existe un autre rapport dans le répertoire First tracking qui te permet de suivre le taux de transfo : "User transformation by first tracking".

A ta dispo pour en discuter.

Agathe
Commentaire de Thomas Beylot [ 22/sept./08 15:14 ]
hello

mille ans après voici donc mon nouveau commentaire sur ce jira.
pour rappel ces rapports avaient été demandé dans le cadre suivant :
- depuis 2005 on travaille avec des agences pour monter des Op de recrutement de clients (les fameux "jeux-concours").
en plus d'un forfait fixe payé à l'agence, nous leur reversons un variable pour chaque email nouveau recruté.
- suite à la fin du jeu, on importe les contacts dans la base et on essaye d'en faire des clients.

=> du coup, l'idée serait de :
- calculer la valeur client d'une OP jeux concours.
- savoir au bout de combien de temps cette valeur client dépasse le coût unitaire du nouvel email recruté.

d'où ma demande d'avoir sur un first tracking donné:
- le nombre de contacts au total
- et un suivi au mois le mois car vu que je n'ai qu'un total sur la période il faudrait que sorte le rapport chaque mois et ça prend du temps :)

j'ai donc jeté un oeil au rapport de suivi acheteur et donc le top effectivement serait de pouvoir avoir ceci avec la possibilité de trier par groupe de tracking et d'avoir le nb de contacts.

Mais je pense qu'un rapport plus simple peut aussi le faire : on filtre sur le groupe de tracking t=x, et sur la période qu'on détermine (de juin 2006 à octobre 2008) on a sur chaque mois le volume d'affaire, comm, nb de paniers etc.
comme ça je pourrais voir à quel mois le budget dépensé est compensé par la comm totale rapporté par la population.

merci

à votre dispo pour préciser, thomas.




[BIN-674] [Abonnement] : Abonnement newsletter Création: 17/mai/10 14:21  Mise à jour: 18/nov./10 18:29  Résolue: 20/mai/10 11:02

Etat: Résolu
Projet: Business Intelligence
Composants: CRM
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Amélioration Priorité: Majeur
Rapporteur: Carole Visser Attribution: Julien Girardet
Résolution: Invalid  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
FRA - France

 Description   
Bonjour,

Nous aimerions suivre le nombre d'abonnés pour chacun de nos groupes d'abonnement.

Il existe déjà des rapports "Subscription" mais ils ne prennent pas en compte la notion de NPAI. Un projet a été mis en place dans le but de les flagger.

Quand serait-il possible de prévoir l'exclusion des NPAI de ces rapports afin que l'on puisse les exploiter?

Merci d'avance,

Carole

 Commentaires   
Commentaire de Agathe Remy [ 20/mai/10 11:02 ]
Bonjour Carole,

Le projet TX actuellement en Production identifie les NPAI des mails applicatifs.
Ceux-ci n'ont rien à voir avec les NPAI 1M et les groupes d'abonnement.

A ta dispo,
Agathe
Commentaire de Agathe Remy [ 07/juin/10 14:23 ]
Bonjour Carole,

Pour info, au 06/06/2010, nous comptabilisons seulement 14 440 comptes dont l'email a été invalidé par PM.
Cela ne me paraît donc pas urgent d'intégrer ces NPAI dans les rapports BI.
Stp, peux-tu me le valider ?

Merci,
Agathe





[APP-31784] Annulation d'une vente : pas de mail au vendeur Création: 15/nov./10 17:33  Mise à jour: 26/nov./10 10:35

Etat: Ré-ouvert
Projet: Application PriceMinister
Composants: Mails
Affecte la/les version(s): 81.1.0 (MEV diverses)
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Majeur
Rapporteur: Christophe Garcia Attribution: Habib-Sylvain Gourguet
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pays:
ALL - Tous
Site: Integ
Projets PM: CoSAV : Gestionnaire de commande

 Description   
Quand le vendeur annule, on dit à l'acheteur qu'on a envoyé un message pour gronder le vendeur : même pas vrai !
Aucun message reçu côté vendeur.

 Commentaires   
Commentaire de Thomas Landru [ 15/nov./10 18:25 ]
Testé sur le tronc, tout est ok :

voir les fiches articles suivantes

annulation post claim : http://bo.dev11.pm.dev/purchase_back?action=itemview&itemid=105024540

annulation post vente : http://bo.dev11.pm.dev/purchase_back?action=itemview&itemid=105024543

Commentaire de Christophe Garcia [ 16/nov./10 11:02 ]
Ce n'est pas ce que l'on peut appeler "un avertissement au vendeur pour qu'il s'assure de la disponibilité de ses produits" (voir message affiché côté acheteur).
Commentaire de Thomas Landru [ 17/nov./10 10:06 ]
Habib il faudrait revoir le contenu du mail suite aux remarques de Christophe.
Commentaire de Habib-Sylvain Gourguet [ 17/nov./10 10:28 ]
Le rappel en question est fait au vendeur lorsqu'une réclamation pour "Non reçu" a été ouverte et que le vendeur a annulé en FO (je vous laisse le soin de tester, bien que DEV11 soit apparemment mort).

Dans le cas d'une annulation pré-claim du vendeur, il peut s'agir d'une rétractation de l'acheteur (que le vendeur soit pro ou part...).

On considère que les vendeurs abusant de la fonctionnalité seront identifiés rapidement via rapports BI.

En partant de ce principe, on peut dire que c'est le mail côté acheteur qui serait incohérent avec les règles citées ci-dessus...

Commentaire de Habib-Sylvain Gourguet [ 17/nov./10 10:29 ]
Je décale (qu'on se mette d'accord ou non... :-).

Pas de traducteurs dispos avant le bouclage de la v81.




[APP-30881] UK - Linkshare - Implémentation des tags Création: 01/sept./10 14:59  Mise à jour: 01/déc./10 17:21  Résolue: 01/déc./10 12:44

Etat: Fermé
Projet: Application PriceMinister
Composants: Affiliation
Affecte la/les version(s): 76.0.1.1
Version(s) corrigée(s): 82.0.1.1

Type: Tâche Priorité: Majeur
Rapporteur: Benjamin Guerville Attribution: Rémi Virlouvet
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File BUY avec 3 items.jpg     JPEG File BUY.jpg     JPEG File FIRST ADVERT.jpg     JPEG File FIRST BUY avec 3 items.jpg     JPEG File FIRST BUY, with improved alignment.jpg     JPEG File FIRST BUY.jpg     PDF File Pixel Integration LinkShare 2010.pdf     PDF File Webservices_LinkShare_QuickStart.pdf    
Pays:
GBR - Royaume Uni
Site: Prod
Projets PM: *** A PLANIFIER ***
Classif FONC: comarket

 Description   
Bonjour,

Nous allons travailler avec la plateforme d'affiliation Linkshare au UK (c'est une société du groupe Rakuten).

1/ Il faut supprimer les tags tradedoubler (ceux mis en place via le JIRA APP-29300), attention pas ceux que nous utilisons pour Twenga.

2/ Il faut implémenter les tags Linkshare (voir doc en pj).

C'est Thomas Springett qui va gérer le projet de notre côté.

Merci
BG

 Commentaires   
Commentaire de Thomas Springett [ 14/sept./10 16:44 ]
Nous avons besoin de 2 tags:

ACHAT:
avec les paramètre:
mid= code priceminister
ord=numero panier
Skulist=product ID et dans le cas d'un "Firstbuy" FIRST_BUY.
qlist=Quantité des article commandé (et dans le cas d'un first buy il faut aissi inclure 1 pour le firstbuy)
amtlist=PriceMinister commission
cur=GBP
Namelist=valear du panier

MISE EN VENTE
mid= code priceminister
ord=Seller ID
Skulist=NEW SELLER.
qlist=1
amtlist=0
cur=GBP
Namelist=Vide
Commentaire de Ariane Baldinger [ 15/sept./10 09:12 ]
OK.
Thomas, est-ce que Linkshare t'as indiqué les 'mid' à mettre ?

Merci de nous les communiquer.
Commentaire de Thomas Springett [ 15/sept./10 09:41 ]
Pas de Mid encore.

Je vais le demander.
Commentaire de Ariane Baldinger [ 30/sept./10 10:56 ]
NB : pour le tag ACHAT, dans le paramètre amtlist la commission doit être multipliée par 100.
Commentaire de Thomas Springett [ 30/sept./10 11:03 ]
Serait il possible de tester les tags avec le MID temperaire?
Commentaire de Ariane Baldinger [ 30/sept./10 11:11 ]
Salut Thomas,

On reprend le même code de traking que celui paramétré pour Tradedoubler ? (i.e.1408140)
Commentaire de Thomas Springett [ 30/sept./10 11:15 ]
Bon question.

Il faut voir si on peut modifier le nom en BO et sur Xiti.

J'aurait le reponse cette aprem.

Thanks,
Commentaire de Ariane Baldinger [ 30/sept./10 11:48 ]
Quelques précisions :

Tag VENTE: on tracke FIRST_ADVERT, on n'utilise pas le paramètre 'namelist", la quantité est fixe "1", ainsi que le 'skulist' = "NEWSELLER"
Tag ACHAT : il s'agit de la quantité d'articles qu'il faut mettre dans le 'qlist'.


Thomas, peux-tu nous fournir les mid temporaires en attendant les définitifs ? Merci

On vise une mise en Prod le 12/10.
Commentaire de Thomas Springett [ 30/sept./10 12:08 ]
Ok pour garder les codes traking creer pour tradedoubler UK, 1408140 toujours.

Merci,
Commentaire de Thomas Springett [ 30/sept./10 16:07 ]
Info sur les tracking.

I would like to give further follow up in regards to technical integration.

You have two options

Private domain w/ 301 redirect . Affiliate links will use the domain linksynergy.priceminister.com. PriceMinister will setup a CNAME on PriceMinister DNS that maps the domain to our click server. Affiliate links will still technically pass through our system via the CNAME reference. Tracking works as normal.

Private domain w/ direct link . Affiliate links will use the domain linksynergy.priceminister.com. PriceMinister will need to setup gateway pages for every variation of click through url we publish (see list below). This is more involved for the PriceMinister as you need setup a process that will handled traffic into the multiple urls, call the LS click server to produce a tracking code and finally redirect the user to the destination.

http://linksynergy.priceminister.com/fs-bin/click?id=xxxx&offerid=xxxx.xxxxx&type=xxxx&subid=0&u1=xxxx
http://linksynergy.priceminister.com/deeplink?id=xxxx&mid=xxxx&murl=xxxx
http://linksynergy.priceminister.com/fs-bin/stat?id=xxxx&offerid=xxxx.xxxxx&type=xxxx&subid=0&u1=xxxx
http://linksynergy.priceminister.com/fs-bin/statform?
http://storefront.linksynergy.priceminister.com/fs-bin/store
Commentaire de Thomas Springett [ 11/oct./10 11:47 ]
Bonjour,

Nous avons un changement de méthode de rémunération affiliée pour linkshare. Jusque 01/02/2011 nous alon payer un % du order value.

Il faut donc changer les attributs:

Maintenons:

amtlist=valeur du panier
cur=GBP
Namelist=PriceMinister commission

et nous remettons

amtlist=PriceMinister commission
cur=GBP
Namelist=valear du panier

pour fevrier.

j'attends toujours le MID de la part de Linkshare.

Merci,
Commentaire de Ariane Baldinger [ 14/oct./10 18:50 ]
en standby : TLE doit s'accorder avec Linkshare sur la techno à mettre en place
Commentaire de Thomas Springett [ 29/oct./10 11:25 ]
Petit changement de format des tags et de wording pour le Firstbuy...


Here it is what it’s need to be done technically
- PM needs to be able to determine if order is completed by new or existing customer.
- If new customer, you will include an extra item denoting this. The item will be defined as skulist=newcustomer, qlist=1, amtlist=0, namelist=New%20Customer. All other elements in the pixel will be configured as per spec. For example, if a new customer purchases SKU1, SKU2 and SKU3, the pixel will look like this:

<img height="1px" width="1px" border="0" alt="" src="https://track.linksynergy.com/ep?mid=36489&cur=GBP&tr=lMh2Xiq9xN0-1qmuLgdHkn_tqpk_qqYBtg&land=20101019_2245ord=12345&skulist=SKU1|SKU2|SKU3|newcustomer&qlist=1|2|1|1&amtlist=2400|5000|1000|0&namelist=Product%20Name%201|Product%20Name%201|Product%20Name%202|Product%20Name%203|New%20Customer">
  
- If existing customer, you will append a “-E” to the end of every SKU value. All other values in the pixel will be the same. For example, if an existing customer purchases SKU1, SKU2 and SKU3, the skulist will look like: skulist=SKU1-E|SKU2-E|SKU3-E.

<img height="1px" width="1px" border="0" alt="" src="https://track.linksynergy.com/ep?mid=36489&cur=GBP&tr=lMh2Xiq9xN0-1qmuLgdHkn_tqpk_qqYBtg&land=20101019_2245ord=12345&skulist=SKU1-E|SKU2-E|SKU3-E&qlist=1|2|1&amtlist=2400|5000|1000&namelist=Product%20Name%201|Product%20Name%201|Product%20Name%202|Product%20Name%203">

Commentaire de Thierry Leforestier [ 10/nov./10 12:09 ]
Bonjour,

Nous avons enfin réussi a faire fonctionner la solution SEO friendly avec LinkShare et pouvons implémenter le pixel tracker comme fourni par LinkShare.
La seule différence pour que tout fonctionne, c'est qu'il faut systématiquement remplacer track.linksynergy.com par trackls.priceminister.co.uk. Sinon tout est pareil.

Si vous avez des questions etc, n'hésitez pas.

Concernant les tests, nous pouvons éventuellement simuler les cookies posés par LinkShare pour vérifier que tout fonctionne en environnement de dev. Je veux bien être inclu dans ce process afin de m'assurer que tout se passe correctement.
Commentaire de Thierry Leforestier [ 22/nov./10 14:50 ]
Donc, comme l'utilisation d'un sous domaine posait des problèmes avec le protocole sécurisé, nous avons utilisé la même méthode que pour l'arrivée de l'internaute, a savoir le ProxyPass.

Il faut donc finalement utiliser à la place de track.linksynergy.com/ep... l'url suivante : https://www.priceminister.co.uk/trackls/ep

Merci !!

Thierry
Commentaire de Thomas Springett [ 22/nov./10 17:16 ]
MID:36489
Commentaire de Rémi Virlouvet [ 22/nov./10 18:23 ]
je résume et j'actualise :
ACHAT:
avec les paramètres:
mid=36489
ord=numero panier
Skulist=product IDs
qlist=Quantité des articles commandés sera toujours 1 (vu avec Damien, on ne peut faire autrement)
amtlist=valeur du panier, par articles
cur=GBP
Commentaire de Rémi Virlouvet [ 24/nov./10 11:34 ]
Thomas, can you please let me know about the new parameters for mise en vente ASAP? I'm setting up the tags right now, and it would be lovely if we could test them together today.
Commentaire de Thomas Springett [ 24/nov./10 11:53 ]
mid= 36489this is correct
ord=Seller IDThis should be orderID of the sales, please let me know if I understood correctly.
Skulist=NEW SELLER. this is correct , recommended name is newcustomer or set yours as newseller without the space.
qlist=1 this is correct
amtlist=0 this is correct
cur=GBP this is correct
Namelist=Emptyyou can leave this empty, recommended name is New%20Customer
Commentaire de Rémi Virlouvet [ 25/nov./10 11:00 ]
en attente d'un support dev pour la somme à multiplier par 100
Commentaire de Rémi Virlouvet [ 29/nov./10 18:45 ]
débloqué par Arnaud. je reprends le param.
Commentaire de Rémi Virlouvet [ 29/nov./10 19:10 ]
<img src="$!{urlBlocker}https://www.priceminister.co.uk/trackls/ep?mid=36489&ord=$purchase.purchaseId&skulist=#set( $existingcu = "-E" )
#set($vCount = 0)
#foreach( $item in $purchase.ItemFormatCollection )
#if($vCount > 0)|
#end
$item.productId$existingcu
#set($vCount = $vCount + 1)
#end&qlist=
#set($vCount = 0)
#foreach( $item in $purchase.ItemFormatCollection )
#if($vCount > 0)|
#end
1
#set($vCount = $vCount + 1)
#end&amtlist=
#set($vCount = 0)
#foreach( $item in $purchase.ItemFormatCollection )
#if($vCount > 0)|
#end
$format.numberRelevant($item.itemSalePrice.multiply(100).convertIntoDefaultCurrency().doubleObjectValue())
#set($vCount = $vCount + 1)
#end
&cur=GBP">
Commentaire de Thomas Springett [ 30/nov./10 16:08 ]
1408140
tracking code for BI
Commentaire de Rémi Virlouvet [ 30/nov./10 16:27 ]
code mis.

tradedoubler désactivé.
Commentaire de Rémi Virlouvet [ 30/nov./10 17:55 ]
tags testés côté param, avec un ou plusieurs articles (pour buy et first buy). tout est ok, jolie URL sur une ligne avec tout ce qu'il faut :)
Commentaire de Rémi Virlouvet [ 30/nov./10 18:00 ]
cms ref

promotions

/promotions/Promotions/GB/Affiliation/LinkShare/MEV - English (UK) (353816)


/promotions/Promotions/GB/Affiliation/LinkShare/FIRST BUY - English (UK) (353883)


/promotions/Promotions/GB/Affiliation/LinkShare/BUY - English (UK) (353815)


/promotions/Promotions/GB/Affiliation/LinkShare - English (UK) (353814)




[APP-27364] Possibilité de gérer à partir de l'application les inventaires Création: 23/nov./09 15:55  Mise à jour: 05/janv./11 12:06  Résolue: 05/janv./11 12:06

Etat: Résolu
Projet: Application PriceMinister
Composants: Produits
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 88.0.0 (VEN-G)

Type: Nouvelle fonctionnalité Priorité: Majeur
Rapporteur: Frédéric Nahum Attribution: Dispatcher (Pôle VEN)
Résolution: Aucune correction envisagée  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: File 20091123_stock_taa_too.csv    
Pays:
FRA - France
Site: Prod
Projets PM: *** STANDBY ***
Classif1: IMPORT
Classif2: export inventaire

 Description   
Nous avons de plus en pus de problème a maintenir les inventaires et les fichiers d'erreur des partenaires passant par FTP, car tous les scripts fait par Eric deviennent obselete avec toutes les modifications de l'application.

Il faudrait pouvoir gérer :

1/ Génération automatique de l'inventaire (chaque jour, lundi ,mar , etc...) sur le FTP du pro
2/ fichier d'erreur (comme accessible, vi BO) à partir du FTP (cf. APP-27790)

 Commentaires   
Commentaire de Frédéric Nahum [ 23/nov./09 15:55 ]
exemple d'inventaire en pièce jointe
Commentaire de Gaël Seguillon [ 01/déc./09 10:08 ]
Nous avons de plus en plus de demandes en ce sens et de moins en moins de capacité à gérer ces flux de façon stable et durable car chaque modification de l'appli demandent ensuite de retravailler les scripts , cela plaide fortement pour la mise en place de webservices permettant aux comptes concernés de venir chercher sans notre intervention manuelle ce type de données.
Commentaire de Edouard Gomez-Vaez [ 07/déc./09 17:32 ]
Bien reçu :-). Nous avons déjà commencer à y réfléchir sérieusement.

Pour l'export inventaire : une solution BI pourrait être moins coûteuse (en charge et en dev) et correspondrait peut-être plus au besoin.
Pour l'export Erreur, et inventaire si l'on ne peut pas passer par le BI, il faut que nous aillons voir Eric, ce que nous ferons dès que la V59 est sortie.
Commentaire de Edouard Gomez-Vaez [ 14/déc./09 17:24 ]
Expression des besoins en cours :

http://pricewiki.lan/Wiki.jsp?page=Conception%20export%20inventaire%20et%20erreurs

Commentaire de Frédéric Nahum [ 16/déc./09 09:56 ]
En ce qui concerne les inventaires, il faut qu'il arrive dans leur FTP donc sur bacchus, le problème est que pour certains pros l'inventaire contient plus de 1 million de lignes donc très long.
Et c'est actuelement le problème le cumul des 'inventaire de plusieurs pro à la suite prenne beacoup de temps et donc en une journée tous les pros n'ont pas temps de passer.
Commentaire de Edouard Gomez-Vaez [ 02/mars/10 11:24 ]
Pour l'instant, c'est plus le problème de copie de fichier qui bloque.
Commentaire de Manuel Sadok [ 05/janv./11 12:06 ]
Ces problématiques sont prises en compte dans le cadre des WS déjà livrés depuis et dans leurs futures évolutions.




[APP-25936] Xiti : visites provenant de campagnes emailing alors qu'aucune campagne emailing n'est en cours Création: 16/juil./09 09:33  Mise à jour: 17/janv./11 19:08

Etat: Ouvert
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): Aucune

Type: Bogue Priorité: Mineur
Rapporteur: Charles Decaux Attribution: Dispatcher (Pôle CTN)
Résolution: Non résolu  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: JPEG File screenshot-1.jpg     JPEG File screenshot-2.jpg    
Pays:
GBR - Royaume Uni
Projets PM: *** CHASSE ***
Classif1: XITI
Classif FONC: webanalytics

 Description   
Hello,

j'ai des visites provenant de "campagnes emailing" selon Xiti, alors que je ne fais aucune campagne emailing en ce moment.
Par ailleurs, les seules campagnes correspondant à "campagnes emailing" sont "Priceletter-uk" et "Parrainage".
Or, nous ne faisons pas de priceletter et le parrainage est encore trop confidentiel pour générer autant de visites.

J'attache 2 screenshots :
- l'un avec tous les groupes de tracking montrant qu'au UK, seuls Priceletter uk et parrainage sont les seuls groupes de trackings en "EPR"
- l'autre montrant les visites xiti issues de campagnes emailling

Serait-il possible de creuser pour comprendre pourquoi on a autant de visites provenant de campagnes emailing ?

Merci

 Commentaires   
Commentaire de Alexandre Garnier [ 16/juil./09 10:20 ]
Pourquoi ya "Parrainage" et "Parrainage_UK" ?

Parrainage contient juste le tracking FILLEUL 20 (classique) qui est utilisé dans les mails de parrainage.
Tandis que Parrainage_UK en contient d'autres et le FILLEUL avec 135414 qui n'est pas utilisé dans les mails...

Au passage aussi, on a le tracking 1352140 (Parrain_WidgetUK) qui est utilisé dans le mail "contact parrainage via widget (texte)" mais c'est le tracking 1352141 (Filleul_WidgetUK).
De plus, les mails de relance utilise le tracking 20 de parrainage classique.

En gros c'est un peu le bordel dans l'utilisation des tracking de parrainage et les templates de mail qui les utilisent.
Alors d'ici à ce qu'il y ai eu une autre erreur dans l'utilisation d'un tracking parrainage à la place d'un autre ...

Sinon, pas vraiment évident de voir d'où ça peut venir. Il faudrait voir avec les rapports BI si les mails de parrainages n'ont pas été beaucoup plus envoyés, ou voir à quels utilisateurs sont assignés ses tracking et si cela correspond bien à des parrainages ou non. Voir aussi si dans l'hitorique des mails UK envoyés via les newsletters ou autre, on a pas utilisé ces trackings par erreur.
Commentaire de Charles Decaux [ 16/juil./09 14:33 ]
Il y a "parrainage" et "parrainage_UK" car j'avais commencé à créer le groupe de trackings jusqu'à ce qu'on me dise que cela relève du dev, qui a alors crée un nouveau groupe de tracking

Ensuite, je pense qu'il y a eu une confusion au niveau des trackings à utiliser pour le parrainage. Lors de la période de recette, je n'ai jamais pu correctement tester, car je ne recevais aucun mail depuis le serveur de dev ou d'integ

Serait-il possible de m'envoyer tous les mailings liés au parrainage au format brut afin que je vérifie que ceux-ci utilisent les trackings corrects ?

Attention, les confusions de trackings parrainage ne sont de toutes façons pas le problème soulevé par ce JIRA. En effet, quand je regarde les stats sous XiTi voici ce que j'obtiens sur la période du 15 juin au 15 juillet :

En effet, sur la période du 15 juin au 15 juillet, voici les stats que j'ai :
-Visites du groupe de tracking "parrainage" : 62
-Visites du groupe de tracking "parrainage_UK" : 3
-Visites du groupe de tracking "priceletter-UK" : 31
--> Total visites de ces 3 groupes qui sont les seuls à appartenir à EPR : 96

-Visites des campagnes emailing dans Xiti : 9821

Soit une erreur de 9725 visites, ce qui est monstrueux et pas logique.

Il faudrait creuser le sujet, car cet écart s'agrandit de jour en jour.

Merci


Commentaire de Charles Decaux [ 23/juil./09 11:00 ]
Hello,

Les visites campagnes emailing ne cessent de croître sans explication rationnelle.

Je retranscris ici une discussion avec XiTi qui aurait tendance a privilégier la piste d'un problème de catégorisation des xtor chez nous.

A votre dispo pour en parler


1.Votre question - 23/07/2009 09:48
 
Bonjour,

dans la vue Sources > sources > sources, je souhaiterais savoir d'où proviennent ces statistiques. Sont-elles récupérées grâce à l'utilisation d'un xtor ? Ou bien sont elles identifiées grâce au referer ?

Merci de votre retour
 
   
 
   
2.Réponse apportée - 23/07/2009 09:55
 
Bonjour,

Les campagnes promotionnelles que vous avez déclarées sont identifiées grâce au XTOR :
- Affiliation et partenaires
- Campagnes d'emailing
- Liens Sponsorisés
...

Tous les autres accès sont classés en fonction du referer :
- Moteurs (i.e. ref=google.com)
- Accès Direct (pas de referer ou poursuite de visite)
- Sites affluents (ref=domaine.com)
- Emails (i.e. ref=gmail.com, seulement les webmails sont identifiés)
...

Cordialement,

Remi Boudard
http://www.atinternet.com
 
 
   
 
   
3.Votre question - 23/07/2009 10:11
 
Merci pour votre réponse.

Que se passe-t-il si une visite provient de gmail avec un xtor qui est lié au type "affiliation et partenaires" ? Est-elle alors classée dans campagnes d'emailing, affiliation/partenaires ou bien dans emails ?

Merci
 
   
 
   
4.Réponse apportée - 23/07/2009 10:28
 
Bonjour,

Si votre xtor est correctement renseigné en tant que "affiliation et partenaires", alors cette visite sera classée dans affiliation et partenariats.
Si une visite est issue d'un webmail et qu'elle n'a pas de xtor, alors elle est classée dans emails.

N'hésitez pas à revenir vers nous si vous avez la moindre question.
Cordialement,
Florian Tamarelle
http://www.atinternet.com
 
 
   
Commentaire de Alexandre Garnier [ 29/juil./09 18:41 ]
La dernière phrase est intéressante : tout clic depuis un webmail est attribué aux mails si on ne met pas de xtor (donc de tracking)

Donc s'il existe des liens dans des mails sans tracking ou que les gens se mettent à linker PM dans leurs mails, ça pourrait expliquer.
Commentaire de Charles Decaux [ 12/août/09 14:42 ]
Vu avec Swan : en fait, le groupe de tracking "Shopping.com" avait été à l'origine crée en tant que campagne email marketing.
Je l'ai modifié par la suite, pour le mettre dans affiliation et partenaires, mais cette modification n'a pas été prise en compte par Xiti.

Je vais faire un msg à Xiti et je vous tient au courant




[APP-31530] Répartition Tracking Création: 27/oct./10 11:09  Mise à jour: 11/févr./11 14:42  Résolue: 02/févr./11 14:52

Etat: Fermé
Projet: Application PriceMinister
Composants: Aucune
Affecte la/les version(s): Aucune
Version(s) corrigée(s): 87.0.0 (CTN-W)

Type: Nouvelle fonctionnalité Priorité: Critique
Rapporteur: Carole Visser Attribution: Emmanuel Letailleur
Résolution: Corrigé  
Estimation restante: Non spécifié
Temps consacré: Non spécifié
Estimation originale: Non spécifié

Pièces jointes: Microsoft Excel Liste des tracking a migrer.xlsx    
Pays:
FRA - France
Projets PM: *** CHASSE ***
WishList: Marketing
Classif1: XITI
Classif FONC: webanalytics

 Description   
Bonjour,

Il y a toujours des problèmes dans l'organisation des groupes de tracking. Pour simplifier la collecte des résultats, j'ai créé un nouveau groupe de tracking "News-Fonctionnalités" dans xiti et dans le BO.

Vous trouverez en pièce jointe la liste des codes présents dans d'autres groupes de tracking et qu'il faudrait affecter dans le groupe News-Fonctionnalités.

A votre dispo si vous avez des questions,

Carole




 Commentaires   
Commentaire de Carole Visser [ 25/janv./11 14:51 ]
Bonjour,

Avez vous pu avancer sur cette demande?

Merci

Carole
Commentaire de Carole Visser [ 25/janv./11 16:39 ]
Bonjour,

Il faudrait également déplacer le tracking "Souhait" présent dans le groupe de tracking "Default" vers le groupe de tracking "Souhait".

Cette modification est assez urgente car nous allons recommencer dès ce soir à réaliser des tests sur le mail applicatif souhait. Il faudrait donc que l'ensemble du VA généré par cet email se trouve dans le même groupe de tracking.

Merci

Carole
Commentaire de Fabrice Feugas [ 26/janv./11 15:52 ]
On va le regarder ASAP.
Commentaire de Renaud Dierickx [ 31/janv./11 17:15 ]
OK, êtes-vous bien sûr de vouloir faire ça ?
Il y aura sans doute des répercussions sur vos rapport BI ?
On traite ça pour la CTN-W.
Commentaire de Julien Meraud [ 31/janv./11 18:14 ]
Oui, on est vraiment sûrs. En fait, il y a des groupes de tracking trop hétérogènes dans lesquels il y a des souhaits, des news etc... ce qui nous contraint à sortir les chiffres tracking par tracking alors que lorsque cela sera corrigé, on pourra sortir les chiffres groupes de tracking par groupes de tracking ce qui simplifiera considérablement les reporting et allégera les fichiers excel.

Par contre, tu me confirmes que comme la dernière fois, l'historique sera lui aussi rebasculé dans les nouveaux groupes de tracking ?
Commentaire de Julien Girardet [ 31/janv./11 18:38 ]
Si la modif consiste à changer l'association tracking/tracking group, alors en effet le VA associé aux trackings concernés sera lié au nouveau groupe de tracking (historique compris).

Julien.

Commentaire de Renaud Dierickx [ 02/févr./11 12:11 ]
On est d'accord que ça ne concerne que la france !
Commentaire de Emmanuel Letailleur [ 02/févr./11 14:52 ]
C'est fait en dev !
[CAJ2011Q1CTN]
Commentaire de Swan Desportes [ 03/févr./11 11:42 ]
Pour les souhaits, on traite le sujet comme suit, de façon transverse aux trois plateformes (FR, ES, UK):
- creation d'un groupe "Souhait" (au singulier), id=30
- deplacement du tracking 30 "Souhait" dans ce nouveau groupe
- déplacement des trackings FR du groupe 219280 (Souhaits) vers le nouveau groupe 30 (Souhait)
- déplacement des trackings FR du groupe 239380 (Souhait) vers le nouveau groupe 30 (Souhait)
Il n'y a pas de groupe "Souhait" ou "Souhaits" en ES et UK

En attendant, la mise en prod, il est toujours possible de créer des trackings dans le groupe 239380 (Souhait)

Merci
Commentaire de Emmanuel Letailleur [ 04/févr./11 12:02 ]
C'est fait mais le nouveau groupe "Souhait" a finalement l'id 1030 et non pas 30.

Je récapitule ce qui a été fait :

- les trackings FR listés dans le fichier excel ont été déplacés vers le groupe "News-Fonctionnalités" (id=235280)
- creation d'un groupe "Souhait" (au singulier), id=1030
- deplacement du tracking 30 "Souhait" dans ce nouveau groupe
- déplacement des trackings FR du groupe 219280 (Souhaits) vers le nouveau groupe 1030 (Souhait)
- déplacement des trackings FR du groupe 239380 (Souhait) vers le nouveau groupe 1030 (Souhait)




Généré à Wed Feb 23 15:55:57 CET 2011 par Christophe Egéa avec JIRA 4.1.2#531.